Five providers touch a single transaction: designing product without controlling the chain

When someone taps “send” in a financial product, they believe they are using an app. What they are actually doing is setting off a chain of independent entities that do not know one another, keep different hours, apply different risk criteria and have no obligation to coordinate. The company that builds the interface — the one that appears on the screen and receives the email when something goes wrong — almost never controls that entire chain.

That, in my experience, is the real difference between building software and building infrastructure: you are not designing a product, you are designing the contract between systems that never spoke to each other.

The arithmetic nobody teaches in the demo

If a transaction crosses five layers and each one is available and responds correctly 99.5% of the time, the probability that all five work at once is not 99.5%: it is roughly 97.5%. Translated, one in forty transactions touches something. At volume, “one in forty” stops being a footnote and becomes your support team.

The most common design mistake is to treat that 2.5% as backend incidents. They are not: they are part of the product, and they are precisely the part the user will remember.

The five layers of a transaction

This is the map I use to place responsibilities before writing a single line of interface. Not every transaction crosses all five, and who occupies each layer changes with the product and the jurisdiction; what does not change is that every layer needs an identifiable owner.

• Layer 1 Identity and verification Who the user is and whether they are allowed to transact. This usually falls to a specialist provider and to the criteria of the regulated entity providing the service.
• Layer 2 Source and eligibility of funds Where the value comes from and whether that origin is acceptable to the next layer. It is the layer that generates the most silent rejections.
• Layer 3 Execution and settlement The movement itself: the rail, its operating hours, its cut-offs and its retries. It is the only layer the industry tends to show.
• Layer 4 Safekeeping and access control Where the value sits while the transaction is in flight and who can move it. Each model — custody by a regulated third party or self-custody by the user themselves — distributes this responsibility differently.
• Layer 5 Last mile Actual delivery to the beneficiary and its visibility at the receiving end. It is the layer you have the least control over and the one that defines the perception of success.

Three rules I apply

1. States are named for where the value is, not for who is holding it

“Pending at provider B” is an architecture leak onto the user's screen. “Received by the beneficiary's institution, pending credit” describes the same reality without forcing anyone to learn your internal diagram — and it is still true on the day you change provider.

2. Every transaction has an owner at all times

In a chain of five actors, the danger is not that one of them fails: it is that the transaction is left with no owner while each party waits for the other. Before launch, the useful exercise is to walk the chain asking, layer by layer: if this stops here, who finds out, how quickly, and what can they do about it? If any layer has no answer, that is where your next incident is.

3. Degradation is a product state

A provider under maintenance should not produce a generic error. It should produce a different, honest experience: what can be done now, what cannot, and when it will be reviewed. Building that state costs a few days of work and it avoids the conversation that really does destroy trust — a user working out on their own that something had been down for hours.

What you learn the day you replace a provider

Swapping out a piece of the chain is the best architecture audit there is. If the change forces you to rewrite interface copy, rename states and re-train support, the provider was not integrated: it was embedded. The discipline that prevents this is boring and it works: your own data model for the transaction, your own vocabulary for its states, and adapters that translate whatever each provider says into that vocabulary.

For the user, all of this comes down to one thing, and it is the thing they are really buying: a counterpart. Someone who answers for the transaction as a whole even though they do not control every one of its pieces. That, in the end, is the part of the job that cannot be outsourced.

Note: informational and educational content based on product experience. It does not constitute legal, regulatory, tax or financial advice, nor an offer of services, and it does not describe the obligations or the activity of any specific provider. Regulated functions, where they exist, are the responsibility of the relevant authorised entity.

Sources

• EBA · Guidelines on outsourcing arrangements — responsibility for functions delegated to third parties.
• BIS · CPMI — chains of intermediaries in cross-border payments.
• ISO 20022 — a common messaging vocabulary between institutions.