Authorized payment protection

Constraint

Colombia was about to make payments irreversible. Bre-B, the instant-payment system from Banco de la República, was coming online. Redeban, the country’s largest payment processor, would run a federated node. Once the money moves, it is gone. There is no chargeback window left to clean up a bad decision.

Equifax already had a fraud platform for merchants reviewing their own card-not-present orders. Authorized push payment fraud is a different problem. It is not a stolen card. It is a real customer who has been talked into sending money to the wrong place. They authenticate successfully, because they are the account holder. The usual legitimacy signals are present and genuine. The fraud sits in the intent behind a clean-looking transfer.

The design problem follows from that. You are intervening against your own customer’s stated request, in real time, without treating them like a criminal. Get the tone or the authority wrong and the product either blocks honest people or fails to stop the ones who need stopping.

Detection was not the hard part. Authority was. Redeban sets a baseline every participating bank has to follow. Banks layer their own policies on that floor. Reviewers work the flagged payments. Redeban can override a bank’s transactions. Banks cannot undercut the network floor, and they were kept from seeing Redeban’s full policy set, for compliance and to limit internal misuse. The interface still had to make authority legible.

Decisive moves

Show whose rule is binding

The product shipped as a stripped-down fork of Payments Fraud. The rules engine still worked as a configuration surface. What changed was hierarchy and visibility. Bank policies sat downstream of Redeban. The screen had to show that subordination without turning the network floor into something a bank user could browse or edit. A flat single-tenant model could not do that.

The review page was rebuilt around the same question: whose policy or model signal caught the payment, and what can this reviewer do. Public product language emphasizes origin and destination risk, velocity into the payee account, account age, type, and status. Those factors and their policy source had to be readable in the same place as the decision. Model reasons stayed at the policy and signal layer. Weights stayed hidden.

Tune the queue for irreversible settlement

The case queue assumed a chargeback window. APP has none. Queue policy, triggers, and assignment had to favor speed and a clear escalation once the money could not be pulled back.

Keep the platform core

Organization and user management stayed: multi-tenant structure, roles, and permissions. They are the least market-specific part of an enterprise product. Rebuilding them buys nothing.

A four-person data science group owned detection. Models trained first on the Colombian network’s data, with planned expansion past that market. The roadmap called for richer streams, including device data, so a reviewer’s confirm or deny could feed training. Review was a labeled outcome, not only a decision point.

I had designed the original rules engine for Kount 360. Deciding which half survived into this market was the useful part of the work. I am a native Spanish speaker, so I sat in the stakeholder calls directly. Design was in the room while scope was still open. The pressure that mattered was refusing to ship a console where network floors and bank rules looked the same, or where the wrong people could see the wrong policies.

What I would have measured

This shipped, and I did not get to see the numbers. I was part of a reduction before results matured. Early adoption was the only outcome available. I am not going to invent a metric past that.

What I would have instrumented: reviewer override rate on network-set rules versus bank-set rules, because a high override rate on the floor would have meant the authority model was still illegible. Then false-positive rate on flagged payments, and time-to-decision under the real-time constraint.

What I can point to is why the category exists. Colombia’s banking association has publicly called instant payments a leading fraud risk, citing Brazil’s experience after Pix. In the UK, mandatory reimbursement moved APP fraud onto institutional balance sheets, which is what turns a detection problem into a product one. Equifax product pages frame the same problem as real-time origin and destination risk analysis for money-mule and social-engineering patterns. The first version made that category usable for a network and the banks under it. Card fraud tooling never had to solve that problem.