In a white-label banking app, each partner assumes the other runs fraud checks - how do you close that gap?

## Why the seam is where the loss happens When one product is delivered by two organisations, each one threat-models what it operates. That is correct and it is not enough. A model has a scope, and scope has an edge, and at the shared interface the two edges meet - usually without overlapping. Everything that should be enforced *at* the boundary is exactly the material each side is most tempted to place on the far side of it, because from either point of view the other party looks better positioned to do it. The white-label banking case makes it concrete. A fintech builds and brands the app; a licensed bank holds the licence and moves the money. Ask each side who runs fraud checks on a new payee and an unusual first transfer: - The fintech says the bank does, because the bank is the regulated institution and owns the ledger. - The bank says the fintech does, because the fintech owns the customer relationship, the device signals and the session context. Both answers are reasonable. The result is that an anonymous fraudster with stolen credentials meets a control that appears in two architecture documents and runs in no system. Money leaves. Then each side's post-incident review finds its own model correct - which it was. ## The structural fix: no half-drawn boundaries The first rule to impose across an organisation is that **a trust boundary must show both sides**. If the far side is another company, it still appears - as an external entity whose responsibilities are written out explicitly. The point is not to model their internals; it is to force the sentence *the control on the far side of this line is X, owned by Y* to be written down. Assumptions that are never written are never checked, and this failure mode is nothing more than two unwritten assumptions pointing at each other. ## Enumerate at control granularity, not layer granularity The usual attempt at this is a responsibility matrix split by layer: network, platform, application, data. It reliably misses the fraud gap, because fraud detection is not a layer. Gaps live in named behaviours: - velocity limits on a newly added payee - device reuse seen across brands or tenants - step-up authentication on a first transfer above a threshold - reconciliation that would notice the pattern the following day So the matrix has to be written one control at a time, each tied to a threat someone actually stated, with one owner and one place the evidence lives. It is longer and duller than a layer diagram, and it is the artifact that finds the hole. A compact form that works on a whiteboard: threat: fraudster adds a payee and drains a balance control: velocity limit on new payees owner: bank evidence: rule log control: device-reuse signal across brands owner: fintech evidence: risk score control: step-up on first transfer owner: ??? evidence: none The third row is the finding. It is visible only because ownership was demanded per control. ## The naming test A fast diagnostic for a shared boundary, usable live in an interview or a design review: take one concrete attack path, then ask both sides to name **the exact system that stops it and the exact log that proves it stopped**. Three outcomes: - Both name their own system: duplication. Wasteful, sometimes deliberate defence in depth, and it is *visible*, which makes it cheap. - One names a system, the other names the first: covered, assuming the claim is true and testable. - Each names the other: a gap. This is the outcome that produces no error, no alert and no ticket until it is exploited. Asymmetric cost is the whole argument: duplication is expensive in effort and obvious; a gap is free until it is catastrophic. That is why, when the boundary cannot be resolved, the correct default is to double up rather than to negotiate. ## When the partner will not engage A principal-level answer has to survive the case where you cannot get the other organisation into a room. Then: 1. Model their side as an external entity with responsibilities **stated**, and send them the list of threats you believe they own. A statement they have seen is a different thing from a hope you never voiced. 2. Treat silence as an unmitigated threat, not as agreement, and escalate it on your own risk path. 3. Add compensating controls on your own side where you can, accepting duplication as the cheaper error. 4. Where you cannot compensate, change the product: lower a limit, delay a first transfer, reduce what the feature can do until the ownership question is answered. ## Keeping it true over time The seam decays faster than either side's interior, because each side ships independently and neither release process consults the other's model. Two habits keep it alive: the shared boundary is re-modeled whenever either side changes what crosses it, and the responsibility list is versioned as part of the interface contract rather than living in a slide from the integration project. If ownership of a boundary control is not in the contract, it will be relitigated during an incident - which is the worst possible moment to discover both parties disagree.