Authorized payment protection

Context

Colombia was about to make payments irreversible. The fraud tooling for that change did not exist yet.

Bre-B, the instant-payment system from Banco de la República, was coming online. Redeban, the country’s largest payment processor, owned by its major banks and licensed as a low-value payment system administrator, would run a federated node on it. Instant settlement is good for people and good for fraudsters for the same reason: 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 built for merchants reviewing their own card-not-present orders. That is a different problem. Authorized push payment fraud is not about a stolen card. It is about a real customer who has been talked into sending money to the wrong place.

Public product framing on equifax.com describes Authorized Payment Protection as real-time analysis of both origin and destination account risk, built to surface money-mule activity and social engineering before settlement. The work on this study was the product surface that made that claim usable for a network and the banks under it.

The inversion

Card fraud asks whether this cardholder is who they claim to be. Authorized push payment fraud asks whether this real, correctly authenticated customer is being deceived right now.

That change breaks most of the assumptions under a fraud product. The victim authenticates successfully because they are the account holder. They authorize the payment on purpose because someone has convinced them they should. 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.

Three layers over one decision

Detection was not the hard part. Authority was.

Redeban is owned by the bank consortium. It sets baseline rules that every participating bank has to follow. Individual banks then layer their own policies on top of that floor. Bank reviewers work the payments that get flagged, confirming or correcting signals from the model.

Redeban can override a bank’s transactions when it believes there is fraud. Banks cannot undercut the network floor. Reviewers need to know whose rule fired and what they are allowed to do about it.

Banks and reviewers were intentionally kept from seeing Redeban’s full policy set. That separation supported compliance and reduced the risk of internal misuse. The interface still had to make authority legible: what is binding, what is local, and what standing the person in the console has, without exposing the network floor as editable configuration.

The interface had to answer questions a merchant fraud tool never asks. Which rules are the network floor? Which did this bank add? When a payment is flagged, whose rule caught it, and what can the reviewer actually do?

That last question is the trust-score problem one layer up. Not only why the model scored this transfer the way it did, but whose judgment is binding and what standing the person in the console has against it.

What we kept and what we cut

The product shipped as a stripped-down fork of Payments Fraud. The useful work was in the stripping.

We kept the platform core: organization and user management. Multi-tenant structure, roles, and permissions are the least market-specific part of an enterprise product. Rebuilding them buys nothing.

We took the rules engine, the case queue manager, and the case review page from Payments Fraud, then cut and redesigned each for APP.

The rules engine still worked as a configuration surface. What had to change was hierarchy and visibility. Bank policies sat downstream of Redeban. Banks and reviewers could not see the full network policy set, both for compliance and to limit internal fraud risk. The product had to show that a bank’s rules were subordinate without turning Redeban’s floor into something a bank user could browse or edit. A flat single-tenant model could not do that.

The case queue manager assumed a chargeback window. APP has none. Once the money moves it is gone. Queue policy, triggers, and assignment had to favor speed and clear escalation under irreversible settlement.

The case review page was rebuilt around authority and model signals. Instead of a general order-details screen, review had to show whose policy or model signal caught the payment and what the reviewer could do. Public product language emphasizes origin and destination risk, velocity into the payee account, account age, type, and status. The review surface had to make those factors and their policy source readable in the same place as the decision.

The org hierarchy change was large in the data model and small on screen. Banks sat downstream of Redeban and only saw their own policies. Most of the complexity lived in how ownership and inheritance were stored, not in a denser UI.

I had designed the original rules engine for Kount 360. Deciding which half of my own prior work survived into a different market was the most useful thing I did on this project.

Working with data science

The models were not mine. The interface between what a model produced and what a human could act on was.

A four-person data science group owned detection. Models trained first on the Colombian network’s data, with planned expansion beyond that market.

Design’s non-negotiable was that the review surface had to show the source of every decision, even when the underlying model stayed proprietary. Model reasons stayed at the policy and signal layer rather than exposing weights. That kept the layered model defensible without handing fraudsters a map of the detection logic.

The roadmap also called for richer data streams, including device data, so that a reviewer confirming or denying a flag could feed labeled outcomes back into training. Designing review as a training input, not only a decision point, changes what you ask someone to record.

How design got upstream

I am a native Spanish speaker, so I sat in stakeholder calls directly instead of reading a summary afterward.

Small mechanism, large effect. Hearing the conversation at the source put design in the room while scope was still open, instead of receiving requirements after the product shape was already fixed.

I owned the policy surface, the review experience, and the cuts from Payments Fraud. Data science owned detection. Product owned prioritization across markets. The design 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. Without that, the layered model would have existed in the data and disappeared in the interface.

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. Rather than invent a metric, here is 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.

What shipped in the first version was a layered policy model, a queue tuned for irreversible settlement, and a review surface that answered whose rule or signal fired and what the reviewer could do about it. The product did not invent a new detection category. It made that category usable for a network and the banks under it. Card fraud tooling never had to solve that problem.