A payment instruction is about to leave your firm that is a hundred times the usual size for that counterparty. What in your systems should stop it, and who should be looking at it?

Work out where the irreversible boundary is

Every control question about payments reduces to one thing: after which point can you no longer take it back? A settlement instruction that has not yet matched at the depository can be cancelled. A matched instruction that has not settled can usually be recalled bilaterally. A delivery-versus-payment settlement that fails leaves both legs where they were. But an unconditional cash transfer through a high-value payment system, once settled, is final in the operational sense, and recovering it depends on persuading the beneficiary or a court, not on operating a reversal.

So the useful question is not "what checks do we have" but "how many of them run before that boundary". A firm with excellent reconciliation and no pre-release control is a firm that will discover this error accurately, the following morning, after the money has left. Put crudely, a detective control on an irreversible action is not a control on the action; it is an early start on the recovery.

The strongest control is that nobody typed the amount

Most payment errors of this shape share a structure: a human decided what to pay, in a screen that let them decide it. The design that removes the whole class is to derive the payment from a recorded obligation instead. An interest payment comes from a schedule. A settlement payment comes from a matched trade. A margin payment comes from a call you have received and reconciled. A coupon distribution comes from an entitlement calculation. In each case the amount, the beneficiary and the value date already exist in the system before anybody looks at a payment screen, and the payment's job is to discharge that obligation rather than to express an intention.

Once that is true, several strong checks become available almost for free. The payment cannot exceed the obligation. It cannot go to an account that is not the beneficiary's standing settlement instruction. It cannot be for a value date the obligation does not support. And a payment with no matching obligation is an exception by construction rather than by pattern-matching. Manual payments still have to exist, because reality generates cases no schedule anticipated, but they should be a small, separately governed, separately monitored path rather than the same path with a different reason code.

Four eyes on the same screen is one pair of eyes

Maker-checker is close to universal and it fails in a specific, predictable way. The checker is shown the transaction the maker constructed, in the same layout, with the same fields populated and the same defaults in place. Their attention is drawn to what is visible, and the error in a payment of this kind is very often what is not visible: a field left at a default, a suppression that was not intended, a component of the payment that the screen does not display prominently because it is rarely relevant.

Making the second pair of eyes worth having means showing them something the maker did not build. Present the payment against the obligation it discharges and highlight the difference. State the amount in words and as a multiple of the recent average for that counterparty and payment type. Show the beneficiary's account with an indication of when it was last used and by whom it was last changed. Force a positive acknowledgement of any field that differs from the derived default rather than accepting silence as agreement. And escalate authority by size, so that an amount two orders of magnitude outside the normal range requires somebody whose job includes knowing what the normal range is.

flowchart TD
    A[Obligation recorded] --> B[Payment derived from obligation]
    B --> C[Automated out-of-pattern checks]
    C --> D{Inside tolerance}
    D -->|Yes| E[Release to payment system]
    D -->|No| F[Escalated approval against obligation view]
    F --> E
    E --> G[Irreversible once settled]

The only interesting boundary on that path is the last arrow, and every control worth having is to the left of it.

What the automated check should look for

Out-of-pattern detection here is unglamorous and effective, because payment flows are far more repetitive than they feel from inside. A per-counterparty, per-payment-type distribution of historical amounts gives you a straightforward test, and the scenario in the question fails it by an enormous margin. Beyond size, the signals that repeatedly matter are a beneficiary account used for the first time or changed recently, a payment that is suspiciously round, a value date outside the usual convention, a currency this counterparty has not been paid in before, and an aggregate for the day that exceeds what the funding plan expected.

Two design notes make the difference between a check and an alarm nobody reads. The threshold has to be relative to the counterparty rather than absolute, because a firm-wide limit is either too low for the largest relationships or useless for the smallest. And the check has to be capable of holding the payment rather than merely recording an observation, which means it has to be positioned in the release path and it has to fail closed. A check that logs a warning while the payment proceeds is documentation.

After release

If it goes anyway, speed is the only lever. Payment systems and correspondent banks have recall mechanisms, and their success depends almost entirely on whether the funds are still identifiable and whether the beneficiary consents. Where the beneficiary believes they were owed the money, or has applied it against a debt they say you owed, consent is unlikely and the matter becomes legal rather than operational. That is why the incident response for this class of error is a same-day escalation to treasury, the correspondent and legal, in parallel rather than in sequence, and why the runbook should exist before it is needed.

It is also why the post-incident work should focus on the screen and the derivation rather than on the individual. An error made by a competent operator working a normal process is evidence about the process.

What the Citigroup payment error established

In August 2020, Citigroup, acting as loan agent, intended to make an interest payment and instead transmitted roughly $900M of principal to Revlon's lenders, because an operator working through a payments interface left fields at defaults which had the effect of releasing the full amount, and the approvals that followed did not catch it. Recovering the money then became a matter for the courts.

Three things in that sequence are worth naming because they are exactly what an interviewer is listening for. The amount was not derived from the obligation the firm intended to discharge, so nothing in the system knew that an interest payment was what was meant. The interface's defaults were the mechanism, not a typing mistake, which is why the answer is about how the payment is constructed and reviewed rather than about care. And the reviewers were looking at the same representation as the operator, so the second and third pairs of eyes added confidence without adding information. A control environment can be fully documented, fully staffed and fully complied with, and still contain none of the three checks that would have stopped this one.

Reconciliation tells you accurately what you did. On an irreversible payment, the only controls that matter are the ones between the derivation of the amount and the release of the instruction, and the strongest of them is that no human chose the number.