- All data is protected by banking-strength encryption, using a combination of cryptographic hash (SHA), symmetric encryption (225-bit Blowfish), and Elliptic Curve digital signatures (equivalent to 1024-bit RSA).
- Secure hash and digital signature protection for imported files.
- Full English Word Conversion module.
- Operator control - No cheques can be printed without entering a password.
- Value limit control - Will not permit authorisation of cheques over defined limits for specific signatories. Optionally cheques may be printed without signatures if passwords are not entered.
- Signature control, which automatically prints signatures on the cheques.
- "A" and "B" signatories (release requires at least one "A" signatory).
- Single cheque and batch authorisation which allows cheques to be sent from the host system as one complete run, and then hands control to Pandora DB for printing.
- Remote authorisation clients are supported, so a signatory can approve payments from his or her own workstation (requires a shared directory on a network server).
- Authorisation levels (limits and A/B signatory status) can be set on a per-bank-account basis, so signatories can have different status on different bank accounts.
- Printing can be distributed to different printers based on the bank account: for example, printing can be done over a WAN at remote sites based on the bank account allocated to the batch.
- Multi-layered access with each layer having access to various features of the system. For example, a user level would not be able to authorise signatures, but could print cheques, and a signatory could authorise the printing of signatures, but not add and delete users etc.
- Audit trails and reports that keep track of all cheques, who printed them, who authorised signatures, amounts and dates etc.
- EFT payments are managed through the same interface. Additional forensic tests can be selected to detect multiple payments to the same account, repeat payments within a specified time window, and changes in the account name / account number correlation. Supervisor overrides and exception lists are provided.
Optional fingerprint reader for stronger user authentication.
Second tractor support, which allows you to have two different cheque stationeries loaded in the printer and select them automatically. Option includes the second tractor hardware unit for the printer.
Multi-printer support, allowing a large print job to be split over two or three printers operating in parallel.
Pandora EFT provides an additional layer of control over EFT payments. Whilst it is common cause that EFT payments are quicker and have lower direct costs than cheque payments, the potential for fraudulent interference is higher.
- There is no physical audit trail, i.e. no piece of paper that can be checked and examined for evidence of tampering.
- The skills needed to audit electronic payment processes are much higher level than those needed to check physical documents. This is because a thorough understanding of how computers store and access data, and how the particular application works, is required.
- The information transmitted to the bank regarding the beneficiary is of two kinds: the human friendly component, which is the payee name, and the numeric account code and bank branch code. Unfortunately, the human-friendly component is ignored by the bank systems. This means that anyone checking the payment details has to verify the numeric bank and account information.
Pandora EFT Features
Authorisation controls allow setting of limits per signatory per bank account, and controlling whether zero, one or two signatories are needed to release a payment. Where two signatories are required, they can be assigned as A or B signatories - again, on a per bank account basis. Two B signatories cannot release a payment: at least one must be an A signatory.
Operator and signatory authentication is by password. Optionally, this can be combined with fingerprint recognition.
Independent Bank Account Management1
Pandora EFT receives payment information from your system and imports it into its own, secured, database. You can supply it with beneficiary bank details, or with the payee name. If you supply only the payee name then bank details are looked up in Pandora's database. This allows a separation of duties between issuing payments and entering and managing beneficiary account details.
Payment batches are checked for duplications. Since the banks' systems do not look at the payee name, there could be multiple payments with different payee names but going to the same bank account. The Duplicate Checking facility checks for multiple payments going to the same account, both within the current batch and in any batches from the previous N days, where you choose the value of N. Payments qualify as duplicates if they are going to the same account and branch code (regardless of payee name), and, optionally, if they are for the same amount.
Some accounts may legitimately receive multiple payments within the checking period, and these may be entered in an exclusion list.
Pandora EFT maintains a history of all payments. Each new payment is checked against the history to see if a previous payment has been made to the same account number with a different payee name, or vice versa. This will detect errors or attempts to divert payments nominally for a certain payee to a different account number - a technique that has been used in the past to divert payments to a fraudster's account.
1This feature is not yet in the standard product but can be supplied on request.