A $900M error, poor system design, and failed internal controls intersected in a recent court case decided in New York.
Citibank, in its role as administrator for loans that a group of lenders, or syndicate, had made to Revlon, was responsible for coordinating between lenders and Revlon. For instance, Citibank would collect interest from Revlon and distribute it to lenders. Citibank was to transfer only $7.8M to lenders, representing Revlon’s interest repayments. Instead, in addition to the interest payment and in error, Citibank transferred nearly $900M of its own money to lenders. Citibank recovered some of the overpayment and sued to recover about $500M, which some lenders refused to return. The judge ruled that under New York law, the lenders did not have to repay the amounts they had received in error.
Because of the way Citibank’s Flexcube computer system was designed, in order to process this particular interest repayment as required (Citibank also needed to make some administrative changes to the loan facility), Citibank had to process both the interest payment and a “dummy” principal payment. Citibank needed to route the dummy principal amount to its internal “wash account” and wire only the interest payment to lenders. That way, only the interest payment would leave the bank, as required; the principal amount would remain in Citibank’s bank account.
Failures in system design, data processing, and internal controls led to an error.
The Revlon transaction was atypical. Most Flexcube transactions involved payments of both principal and interest to lenders and did not engage the wash account. Perhaps as a result, by default, Flexcube would wire the full amount of principal and interest entered unless the person inputting the transaction checkmarks three fields and inputs the wash account number in the appropriate field. The applicable procedure manual outlined these requirements. The red and green rectangles in Figure 1 below highlight the records to be check-marked and updated with the wash account number.
Additionally, Citibank’s “six-eye” approval procedures required three persons to verify Flexcube transactions. The maker enters the transaction, the checker reviews and verifies the entries, and the approver double-checks and, if appropriate, approves the transaction.
The maker entered the Revlon transaction, emailed the checker requesting approval, and informed him that Flexcube would wire the interest and send the principal to the wash account. The checker raised no issues. He asked the approver to authorize the transaction and explained that Flexcube would wire the interest and send the principal to the wash account. The approver signed off, instructing the checker to “…proceed. Principal going to wash.”
The final system check was a screen warning: “Account used is Wire Account and Funds will be sent out of the bank. Do you want to continue?” The checker clicked “YES,” wiring $900M plus the $7.8M interest payment to Revlon’s lenders.
The following day, while performing reconciliations, the checker discovered the error.
Only the principal field had been check-marked in Flexcube (highlighted by the green rectangle above). The maker, checker, and approver had all mistakenly believed that this was enough to direct the principal payment to the wash account. In error, the other two fields, highlighted in red rectangles in Figure 1 above, had not been checked.
What could have prevented the error?
The following system and internal controls may have prevented the overpayment:
- The onscreen warning described above could have been more informative, making it more likely that the approver would catch the error. The warning could have spelt out the amount ($900M) and the nature of the payments (principal plus interest) to be “sent out of the bank.” Instead, the warning merely stated the obvious—funds were leaving the bank.
- Implementing additional automatic validation controls, including logic, relational, or completeness checks, may have prevented the error. Once Flexcube detected the wash account number in the principal field, these types of controls could have blocked processing until the inputter checkmarked all three required fields.
- Ideally, the system could have been designed to limit the number of entries needed to effect wash account transactions. For instance, it may have been simpler to have a single record (intuitively named “Internal Payments” as an example) requiring only an amount and a wash account number. Any other field requirements could be addressed on the backend.
- Perform reconciliations at day’s end instead of the next day or perform same-day reviews of exception reports or transaction logs to catch and perhaps reverse or correct errors sooner.
- Perhaps the review procedures needed more safeguards against “review hypnosis.” Review hypnosis occurs when a reviewer is lulled into a false sense of comfort and reviews almost by rote. With an atypical transaction, there is a risk that review and sign-off proceed mechanically, according to the requirements for typical transactions.
Review hypnosis may also occur because of a subconscious halo effect or association of positive attributes to a subordinate’s skills and diligence. A positive impression of a subordinate’s skills—not necessarily unfounded—could lead to less rigorous reviews or a lower threshold for accepting the subordinate’s work than would otherwise exist.
To guard against review hypnosis, reviewers should bear this phenomenon in mind and ensure that reviews are adequate. For instance, reviewers should understand what they are reviewing and perhaps go back to procedures manuals or checklists to confirm requirements. Reviewers should request and review screenshots and other supporting documentation to give themselves the appropriate levels of assurance.
Implement application controls, including effective onscreen warnings, validation controls, and exception reporting to reduce the likelihood of processing errors. Beware of review hypnosis and apply an appropriate level of rigor and skepticism to reviews; trust but verify.
For more information on system design and application controls, see Information Technology PolicyPro, Chapter 2 – Systems Acquisition, Maintenance, and Disposal; Chapter 3 – System Acquisition, Implementation and Maintenance; and Chapter 9.04 – Application Security Controls. For more on internal controls, see Finance and Accounting PolicyPro, Chapter 6 – Internal Controls.
Policies and procedures are essential, but the work required to create and maintain them can seem daunting. Finance and Accounting PolicyPro, Not-for-Profit PolicyPro, and Information Technology PolicyPro, co-marketed by First Reference and Chartered Professional Accountants Canada (CPA Canada), contain sample policies, procedures, checklists and other tools, plus authoritative commentary to save you time and effort in establishing and updating your internal controls and policies. Not a subscriber? Request free 30-day trials of Finance and Accounting PolicyPro, Not-for-Profit PolicyPro, and Information Technology PolicyPro here.
Latest posts by Apolone Gentles, JD, CPA,CGA, FCCA, Bsc (Hons) (see all)
- Vendor master file blunders caused a $2.7M loss - June 2, 2021
- ISO 14001:2015 Confirmed - May 6, 2021
- A $900M error, poor system design, and failed internal controls - April 7, 2021