A customer who has banked with the same institution for years is known to it in a number of different ways:
- To the onboarding system that ran the identity checks, the customer is a passport, an address, and a date on which verification was completed.
- To the fraud engine, the same customer is a pattern of devices, locations, and spending that it scores in real time.
- To the anti-money-laundering system, a risk rating and a stack of alerts, most of them cleared long ago.
- To the app and the contact centre, a name, a photograph, and a service history.
Four example systems, four versions of one person, and they do not agree with one another. When that customer moves house, the bank often hears about it three times, because three of the four systems have no idea the other two have already been updated. The customer notices the seams. So, in a different way, do the people who defraud banks for a living.
Every retail bank has some version of this customer, and the fragmentation is not the failing of one institution. Fraud, financial crime, KYC, and customer experience grew up as separate disciplines, with separate teams, separate budgets, and separate systems, and for a long time that separation held up fine. It holds up much less well now, because the four have collapsed into a single engineering question, and banking identity is the name for the answer.
Does the bank hold one reliable, current, shared understanding of who its customer is, and can every function that needs it read from and write to that understanding in close to real time? The wider series framed identity as the point where trust stops being a claim and becomes an engineering output (see Trust Is an Engineering Output).
Inside a bank, identity is turning into the thing the whole institution runs on.
The seamed customer
Look first at what the seams cost, because they are expensive on both sides at once. For the customer, they show up as friction. A repeat verification for a transaction the fraud engine did not recognise, a wait while a legitimate payment is held, a request to re-confirm details the bank already holds, an address updated in one channel while another channel keeps posting to the old one. None of this is catastrophic. All of it, accumulated across millions of customers, is the texture of a bank that feels harder to deal with than it should.
The other side is where it gets serious.
The same seams are an attack surface, and financial crime lives in the gaps between the four systems. A synthetic identity, assembled from real and fabricated fragments, can pass onboarding because the KYC system checks documents rather than coherence, and then behave well enough that the fraud engine, which never saw the onboarding anomaly, has no reason to look twice. An account takeover exploits the fact that the fraud engine sees a device change the AML system will never hear about, while the AML system sees a transaction pattern the fraud engine treats as somebody else’s problem. No single system holds the whole picture of the customer, so no single system can see the whole picture of the attack. The criminal’s real advantage is not sophistication. It is that the bank’s view of the customer is split four ways and the criminal’s view of that same customer is whole.
How identity got fragmented
The fragmentation was built one sensible decision at a time. The KYC system arrived to satisfy onboarding obligations, and those obligations are real: the global standard requires a bank to identify and verify the customer, identify beneficial owners, understand the relationship, and monitor it on an ongoing basis (FATF, 2012). The AML monitoring system was bought separately, often from a different vendor, and keyed on accounts and transactions rather than on people. The fraud engine came in for real-time scoring, keyed on sessions and devices. The customer relationship system was built for service, keyed on a contact record. Each was the right tool for its job, procured by the team that owned that job, on its own timeline.
What none of them shared was a canonical idea of the customer. Each held its own identifier for the same human being, and nothing tied those identifiers together into one durable customer identity. So the bank ended up able to answer four narrow questions well and the one broad question, who is this customer and what do we currently know about them, not at all. This is the state most KYC architecture is in: strong at the point check, silent on the whole.
The regulatory current now runs the other way on both sides of the Atlantic, which is worth noticing. In the United States, FinCEN’s customer due diligence rule already requires banks to identify and verify the beneficial owners behind their legal-entity customers and to keep that understanding current, and a February 2026 order recast the refresh obligation on a risk basis rather than as a mechanical repeat at every new account (FinCEN, 2016; FinCEN, 2026). In the European Union, the 2024 anti-money-laundering reform moves the bloc onto a single rulebook and stands up a central authority to supervise it, with directly applicable rules on customer due diligence and beneficial ownership designed to make that data consistent across institutions rather than bespoke to each (European Parliament and Council, 2024). Different regimes, one direction of travel, toward shared and coherent identity. A bank whose own AML data cannot be reconciled across its four internal systems is starting that journey a long way back.
What a unified identity layer looks like
The fix is a unified identity layer, and it is worth being precise about what that means, because it is not another copy of the data in a warehouse. It is one canonical, current, authoritative record of each customer, built by resolving the fragments the four systems already hold into a single entity. Entity resolution, the work of deciding that this passport, that device pattern, and that contact record all refer to the same real person, is the hard technical core of it, and it is never perfectly clean, which is exactly why it has to be engineered rather than assumed.
The layer holds the durable answer to who the customer is, and links out to the signals each function produces: the KYC status and its evidence, the AML risk rating and its alerts, the live fraud signals, the service history. The point is not that one team now owns everything. The point is that any function can see the whole customer without having to own all of the customer. The fraud engine can factor in that onboarding flagged something odd. The AML system can see that the fraud engine just watched the customer’s device and location change. Onboarding can stop asking for what the bank already holds. The identity layer becomes the shared, low-latency, authoritative view that every other system reads from and contributes to, and building that view out of messy source data is a serious piece of identity engineering rather than a reporting exercise.
The security architecture that supports it
Here is the part that a bank has to take seriously before it builds any of this, because getting it wrong turns an asset into a liability. A unified identity layer concentrates the most sensitive data in the entire institution into one place. That is precisely what makes it valuable, and precisely what makes it the highest-value target the bank owns. Unify identity without hardening it and the result is a better-organised honeypot.
So the unification and the protection are the same project, and banking security has to be designed into the layer from the first day rather than added once it works. That means access that is fine-grained and purpose-limited, so the fraud engine reads the fields it needs for fraud prevention and nothing more, and the contact centre sees a service view that does not expose the full financial-crime picture. It means strong identity for the workloads and the people reaching the layer, not just for the customers described in it. It means tokenising the most sensitive attributes, so that a breach of one consumer does not spill raw identity data. And it means a complete, tamper-evident record of every read and write, both because a supervisor will eventually ask who saw what, and because the bank itself needs to know. Get this right and the concentration of identity is a strength. Get it wrong and it is the worst single point of failure a bank could design. This seam between unifying data and defending it is the ground Sakura’s Security practice works on with a bank’s identity teams.
What changes once it exists
Come back to that customer, and follow what a working identity layer changes for them and for the bank at the same time. The address update lands once and every channel reflects it. The legitimate payment clears because the fraud engine can see the customer is exactly who the rest of the bank already knows them to be. Onboarding to a new product takes minutes because the bank reuses what it verified years ago instead of starting over. The friction that made the bank feel hard to deal with mostly disappears, and it disappears for the same reason the bank gets safer.
Because the criminal loses the seams. Synthetic identities are harder to sustain when onboarding, fraud, and financial-crime signals resolve to one view that has to stay coherent over time. Account takeover is harder when the device change the fraud engine sees and the transaction pattern the AML system sees are looking at the same customer record rather than two strangers. Fraud prevention and financial-crime detection stop being separate contests the bank fights with half the picture each.
And the bank gains the property the whole series has been circling. It can answer, for any customer, what it knows and how it knows it, on demand and with the evidence attached. That is trust as an output of the architecture rather than an assertion in a policy, and it turns out to run on a clean identity foundation. A bank that builds one is not a slow bank: Xapo Bank reached production on a tightly governed stack in weeks rather than quarters, because the foundations were engineered once and everything else inherited them.
The unified identity layer that all four functions read from and write to has to be built out of the fragmented systems a bank already runs, and constructing that resolved, current, authoritative view of the customer is the work Sakura’s Data & AI practice does inside financial institutions.
References
European Parliament and Council, 2024. Regulation (EU) 2024/1624 of the European Parliament and of the Council of 31 May 2024 on the prevention of the use of the financial system for the purposes of money laundering or terrorist financing (Anti-Money Laundering Regulation). Official Journal of the European Union, L, 19 June. Available at: https://eur-lex.europa.eu/eli/reg/2024/1624/oj [Accessed 10 July 2026].
Financial Action Task Force, 2012. International Standards on Combating Money Laundering and the Financing of Terrorism and Proliferation: The FATF Recommendations (updated). Financial Action Task Force, Paris. Available at: https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Fatf-recommendations.html [Accessed 10 July 2026].
Financial Crimes Enforcement Network (FinCEN), 2016. Customer Due Diligence Requirements for Financial Institutions, Final Rule. 31 CFR Parts 1010, 1020, 1023, 1024 and 1026. US Department of the Treasury. Available at: https://www.federalregister.gov/documents/2016/05/11/2016-10567/customer-due-diligence-requirements-for-financial-institutions [Accessed 10 July 2026].
Financial Crimes Enforcement Network (FinCEN), 2026. Order Granting Exceptive Relief from the Beneficial Ownership Requirements for Legal Entity Customers. US Department of the Treasury, 13 February. Available at: https://www.fincen.gov/system/files/2026-02/FinCEN-Order-CCDExceptiveRelief.pdf [Accessed 10 July 2026].