.jpg)
Walk into the AP function of any large business and the vendor master tells the same story. The same supplier appears two or three times, under different spellings, a legacy DBA, an acquired entity, a new bank account. Each record was onboarded separately, verified separately, paid separately. None of them know about the others. That is not a data hygiene problem. It is a verification problem, and it is the reason supplier identity needs to be rethought as a graph rather than a row.
The duplicate-supplier problem
Most enterprise vendor masters carry somewhere between 15 and 30 percent overlap by entity. Procurement sets up a supplier for a one-off purchase. Finance creates another because the bank details changed. A business unit onboards the same entity through a different portal because nobody could find the original. Mergers, rebrands and changes of beneficial owner add further layers.
The result is predictable. Payments split across duplicate records. Discount terms misapplied. Spend analytics that understate concentration with key suppliers. And, more dangerously, a verification process that has to start from zero each time, because there is no reliable link between the new record and the work already done on the old one.
Traditional master data tooling treats this as a matching problem. Fuzzy logic on names, addresses and tax IDs. That helps at the margins, but it does not address the underlying cause. Identity is being captured as a static record inside one buyer's system, not as a living thing the supplier can carry between relationships.
Identity as a graph
A supplier is not a row. It is a set of attributes that move together, change over time and connect to other entities. A useful identity model has at least five layers.
The legal entity layer covers the formal record: registered name, jurisdiction, company number, registered address, VAT or tax identifiers. This is the foundation, and it is the layer most KYB tools focus on.
The bank routing layer covers the accounts the supplier actually receives money into, verified against the legal entity. This is where Confirmation of Payee and similar account-name checks earn their keep, and where most invoice redirection fraud is caught or missed.
The beneficial ownership layer covers the people who ultimately control the entity. Sanctions screening lives here. So does politically exposed person screening, and the question of whether ownership has changed in ways that should trigger fresh diligence.
The payment history layer covers what has actually happened in commercial reality: invoices raised, paid, disputed, settled late. This is the layer that turns a verified counterparty into a trusted one.
The behavioural fingerprint layer covers how this supplier interacts with the network. How it submits invoices, the cadence and channels of its communications, the patterns that, when they shift suddenly, are the strongest early signal of compromise.
On their own, each layer is partial. A KYB tool that stops at legal entity tells you the company exists. A bank verification tool that stops at the account tells you the routing matches today. Neither tells you whether the supplier on the invoice this morning is the same supplier you have been paying for three years. The graph is what makes that question answerable.
What changes when identity is portable
When the graph is held outside any single buyer's vendor master, three things change.
Onboarding compresses. A supplier that has already been verified for one buyer in the network does not need to repeat the exercise for the next. The legal entity, bank routing and beneficial ownership have already been established and are kept current. Onboarding becomes a question of contract terms and commercial fit, not a six-week identity exercise.
Fraud signals get sharper. The strongest indicator of invoice redirection or business email compromise is deviation from an established pattern. A new bank account, a new contact, a sudden change in invoice format. If you only see your own history with the supplier, those signals are weak. If you can see how the supplier behaves across the network, the same signals become high-confidence flags.
Reporting cleans itself up. Spend rolls up to real entities rather than to whichever record happened to be used for that purchase order. Concentration risk becomes visible. Procurement gets a defensible view of category spend. Finance can answer 'how much do we pay this supplier' without three caveats.
The compliance angle
For regulated firms, this is not optional. The regulatory direction of travel assumes you can demonstrate, on demand, that you know who you are paying and why.
Confirmation of Payee, now embedded in UK payments, treats the legal-entity-to-bank-account link as a basic hygiene check. The supplier identity graph extends this from a one-time check at payment to a continuous property of the relationship.
Sanctions and AML expectations under the UK and EU frameworks, and the equivalent OFAC regime in the US, require ongoing screening, not a single check at onboarding. Beneficial ownership changes, parent company restructurings, jurisdictional shifts: all of these need to surface promptly. A static record in a vendor master does not do this. A live graph does.
DORA, for firms in scope, treats third-party concentration and the integrity of payment operations as an operational resilience question, not just a procurement one. Knowing precisely which suppliers you depend on, and whether their identity is stable, is a prerequisite to passing that test.
The point is not that any of this is new. The point is that the obligations are continuous, and the supplier identity graph is the structure that lets you meet them continuously, rather than scrambling at audit time.
What to ask of any vendor claiming to do this
If you are evaluating supplier verification or KYB tools, the framing above gives you a sharper set of questions than the usual feature checklist.
Does the verification persist across buyers, or does it sit inside your own portal and need to be redone by every other firm the supplier works with? If it is the latter, you are buying a faster onboarding form, not a verification network.
Is the bank account verified live against the legal entity, and re-verified when it changes, or is it captured once at onboarding and trusted thereafter? The second is where most invoice redirection fraud succeeds.
How are behavioural changes detected, and what is the threshold for surfacing them? A tool that only reacts to confirmed incidents is reacting too late.
What does the audit trail look like when ownership, bank details or contact information change? Who saw what, when, and what was approved? Regulators will ask. So will your auditors.
Who has rights over the supplier's own record? The supplier should be able to maintain its own identity, see who is verifying it, and consent to what is shared. A model where buyers hold all the data, and suppliers re-key it into every portal, does not scale, and it does not align with where data protection regulation is heading.
The shift in framing is the point. Supplier verification is no longer 'do we trust this counterparty enough to onboard it'. It is 'is this the same supplier we already know, behaving the way we expect, with the relationships and accounts we have already verified'. That question can only be answered well when identity is a graph, not a row.
.jpg)
.jpg)
