Fragmentation Is the Enemy: What a Fraud Panel Got Right

In the public Fintech Fireside Asia recording Asia's Multi-Billion-Dollar Fraud Crisis: Can Fintechs Still Build Trust?, the discussion brings together people who see risk from different parts of the payment ecosystem. Their starting points span identity and risk data, payments, commerce, and payment infrastructure. The discussion repeatedly returns to the problems created when signals and responsibilities sit apart. RTD's editorial synthesis is simple: fragmentation is the enemy.

That synthesis is useful because it moves the fraud conversation away from the search for one more signal. Most financial institutions already have many signals. They know when a device is new. They can see when login behavior changes. They may receive payee information, payment-rail context, account history, and scam reports. The structural weakness is that those facts often arrive in different systems, at different times, with different owners. No single decision sees enough of the journey to explain what changed.

Attackers do not respect those organizational boundaries. A scam can begin with a message, continue through a legitimate login, add a new payee, survive an authentication challenge, and end with a payment that looks ordinary when viewed alone. Every individual control can operate as designed while the combined journey remains dangerous.

That is why fragmentation is not an integration inconvenience. It is a decisioning problem.

An anomaly needs something to differ from

Fraud teams often talk about anomaly detection as though the anomaly lives inside one event. Usually it does not. A transfer amount is not inherently abnormal. A new device is not inherently malicious. A first payment to a payee is not inherently fraudulent.

Each becomes meaningful only when compared with the account's prior behavior and the sequence surrounding the event.

Whole-journey visibility provides that comparison. It lets a decision ask questions such as:

• Did this payment follow a familiar login pattern or a sudden device change?
• Was the payee added during a normal session or immediately after unusual credential activity?
• Is the payment consistent with prior amounts, timing, and channels?
• Did the person encounter a relevant warning and then alter the payment details?
• Does the sequence support Accept, Step-up, Review, or Block?

The point is not to create a giant profile that absorbs every available fact. More data can create more noise. The point is to connect signals that share a decision context, preserve when they occurred, and make the resulting action explainable.

A flat payment record says what happened at the end. A journey says how the account arrived there. That difference is what makes deviation visible.

The founding thesis behind a decision engine

The discussion's recurring concern about fragmented context closely matches the thesis behind Run-True Decision's Fraud Decision Engine. FDE is built as a decision engine, not as a scorer for one isolated event type.

Its current architecture can evaluate different stages of a digital financial journey through a shared pipeline and combine the event with contextual, behavioral, device, network, and historical signals supplied to that decision.

That is a product-architecture statement, not a deployment claim. It does not mean every institution already has every signal connected, or that connecting them solves fraud by itself. Journey visibility is only useful when the source data is timely, correctly mapped, and governed. Missing context must remain visibly missing; it should never be silently invented.

The architectural goal is simpler: give each decision enough relevant context to choose the least disruptive safe action and explain why. Familiar activity can end in Accept. A meaningful but resolvable deviation can lead to Step-up. Ambiguity that needs human judgment can enter Review. Strong, corroborated risk can lead to Block.

This four-decision vocabulary matters because a fragmented stack often collapses very different actions into one vague intervention bucket. A verification challenge and a human investigation are not the same experience, do not have the same evidence needs, and should not be measured as though they were interchangeable.

APP scams expose the limit of authentication

The panel also acknowledged something the industry needs to say more often: there is no magic bullet against authorized push-payment scams.

These scams are difficult precisely because many conventional controls still succeed. The person may use the usual device, enter the correct credentials, and complete an authentication challenge. The payment is technically authorized, but the intent may have been shaped by impersonation, urgency, fear, or a fabricated investment story.

This creates a crucial distinction between authentication and genuine authorization. Authentication can establish that a credential, device, or person completed a required step. It cannot, on its own, establish that the person understood the beneficiary, the purpose, and the consequences of the payment. A coerced tap can still be a valid tap at the protocol level.

That is not an argument against authentication. Step-up remains an important response when risk changes. It is an argument against treating a completed challenge as universal proof that the underlying payment is safe.

Run-True Decision is exploring this distinction as a design problem. No current FDE capability determines whether apparent consent was genuine, and this article should not imply otherwise. The open question is how future decisioning can combine authentication results with payment context, behavioral deviation, scam indicators, and clear evidence without pretending that software can read a person's mind.

Contextual friction beats uniform friction

If there is no single control that stops every scam, the practical answer is layered, contextual friction.

Uniform friction is easy to describe and frustrating to live with. Challenge every payment above a fixed line. Show the same warning to everyone. Route every unfamiliar event to Review. These controls create activity, but repetition teaches people to click through them. They also burden familiar, low-risk behavior without necessarily interrupting the moments when a scam narrative is strongest.

Contextual friction asks a better question: what changed here, and what intervention fits that change?

If the device, session, payee, and payment pattern are familiar, Accept may be appropriate. If one meaningful feature deviates but the wider context remains coherent, Step-up can ask for additional evidence. If several signals conflict, the case can move to Review for human judgment. If evidence strongly supports compromise or deception, Block can prevent the payment from proceeding.

Warnings should be contextual too. A generic banner saying "beware of scams" quickly becomes background. The panel argued for warnings tied to current typologies rather than generic prompts. RTD's editorial recommendation is to turn that principle into questions such as: Are you being told to keep this payment secret? Is someone claiming that your money must be moved to a safe account? Were you promised guaranteed returns or pressured to act immediately?

The intervention works not because it adds another click, but because it introduces the right question at the moment of deviation.

Consent is the next hard decisioning problem

One of the discussion's hardest points is that a person acting under coercion may press "authorize" without giving meaningful consent. That observation creates a difficult boundary for fraud architecture.

Systems are good at recording events: a login succeeded, a challenge was completed, a payee was added, a payment was submitted. They are less capable of interpreting the human story linking those events. Scam victims can look operationally compliant because the attacker has coached them through every control.

A responsible design response begins with humility. Do not claim to infer coercion with certainty. Do not turn one behavioral deviation into an automatic Block. Do not treat a completed Step-up as a permanent trust token. Instead, preserve the evidence, look for corroborating context, and keep the decision proportionate.

That may mean combining a specific scam warning with Step-up. It may mean Review when the payment remains ambiguous. It may mean Block when account-compromise evidence and payment risk reinforce each other. The important shift is from asking only "was the challenge completed?" to asking "what does the full sequence support?"

A forward-looking question: Know Your Agent

The same logic may matter as software agents begin to initiate or prepare financial actions on behalf of people and businesses. Identity checks designed for humans and organizations do not fully answer what an agent is permitted to do.

RTD uses Know Your Agent here as editorial shorthand for a forward-looking authorization problem. It is not a current RTD product or a claim about a settled regulatory category. The panel's agentic-payments discussion considered mandates, consent, limits, revocation, and audit trails; RTD's analysis turns those themes into the following design questions.

• What is the agent permitted to initiate, and within what limits?
• Who granted the mandate, and how can it be revoked?
• Can the mandate be narrowed by payee, channel, amount, time, or purpose?
• What evidence shows that a particular action stayed within scope?
• When should the action lead to Accept, Step-up, Review, or Block?

An agent's identity matters less than its mandate if the mandate is vague, irreversible, or impossible to audit. The control needs to bind identity, scope, context, and revocation into one traceable decision.

Run-True Decision has no KYA capability in progress. The relevance is conceptual: delegated software authority could make fragmented decisioning even more dangerous. A payment system that sees only the final instruction may not know whether an agent stayed within its mandate, just as a fraud system that sees only the final click may not know whether a person acted under coercion.

A practical fragmentation audit

Fraud and risk leaders do not need to wait for a major platform replacement to test this thesis. Select one recent ambiguous payment journey and ask:

1. Can the team reconstruct the sequence from login through payment without switching among several records?
2. Which contextual signals were available at decision time, and which arrived too late?
3. Did a completed Step-up become the end of the analysis, or one piece of evidence?
4. Was the warning specific to the apparent scam narrative?
5. Can reviewers explain why the outcome was Accept, Step-up, Review, or Block?
6. If a delegated agent initiated the action, could the team prove its mandate and scope?

If the answers live in different systems or depend on someone's memory, fragmentation is shaping the decision. The first improvement is not necessarily another model. It may be a better event map, a clearer evidence contract, or one decision trail that connects the journey.

Fragmentation, consent, and agentic identity are three versions of the same challenge. A safe decision needs to understand how an action emerged, not merely observe that the final button was pressed.

Editorial close: Compare one of your own payment journeys against this fragmentation diagnosis. Where does context disappear before the decision is made? Talk to us if you want to compare notes.