Knowing your customer is a data modelling problem

A support agent, a risk analyst and a finance controller each open the same customer on the same afternoon, and each sees a different person. The agent sees an account in good standing with a verified identity document on file. The analyst sees a profile flagged twice and cleared twice, against a pattern of transfers the agent's screen does not carry. The controller sees two customer identifiers reconciling to one bank account, and has raised a ticket about it. None of them is looking at bad data. Each system is internally consistent and is answering the question it was built to answer.

The institution would say, accurately, that it knows this customer: an identity was captured at onboarding, verified against a registry, and filed where an auditor can retrieve it. That obligation has been discharged. What has never been decided is where the customer — the single, continuous, changing thing the business actually transacts with — is supposed to live.

Two different customers, one word

The phrase is doing double duty, and its two jobs pull in opposite directions.

The compliance sense is a point-in-time assertion: this person presented these documents, the documents checked out against an authoritative source, and here is the evidence. It is deliberately static, because its purpose is to be defensible later. Re-opening it is an exception process.

The operational sense is the opposite — a customer continuously accruing meaning. Devices, beneficiaries, failed logins, limits raised and lowered, a dormancy that ended, a complaint, a salary credit that stopped arriving. None of that belongs in the compliance file. None of it is optional to the decisions the business makes hour by hour.

Institutions build a strong system of record for the first and treat the second as something reporting will eventually assemble. The result is that the firm's confidence about a customer rests on a static record, while its decisions rest on a reconstruction nobody owns.

No system owns the customer

Each system holds the customer under the key that suited it. The core ledger keys on an account number, the mobile channel on a device and a phone number, the card platform on a scheme token, the complaints tool on whatever the agent typed, the compliance file on a national identity number. Every one of those is a legitimate primary key for its own purpose, and none of them is the customer.

Joining them is the work, and it is less deterministic than the architecture diagram suggests. A phone number moves between people. One person holds accounts under a maiden and a married name. A joint account has two owners and one key. A merchant is a customer of the retail side and a counterparty to the settlement side. Where a national identity number is present it resolves most of this cleanly, which is exactly why its absence elsewhere — on older records, on non-resident customers, on accounts opened before the field was mandatory — tends to go unexamined.

The two ways the join fails are not symmetrical. Splitting one person into two customers understates exposure: a limit applies twice, a risk signal attaches to the half that did not trigger it, and an aggregate the institution believes is a ceiling is not one. Merging two people into one customer is worse in kind rather than in degree — it is a confidentiality failure, discovered by a real person looking at someone else's money, and it is the direction that produces an incident rather than a variance.

A customer record is a claim with a date on it

Almost everything in a customer record decays. An address, an employment status, a declared source of funds, a risk rating, an identity document with an expiry. Each was true when it was recorded and is a claim thereafter.

This is where one modelling choice decides what stays answerable. Hold the customer as a current row, and every update destroys the state it replaced. The warehouse then reports the present faithfully and cannot reconstruct any past — while every genuinely interesting question about a customer is asked in the past tense. What did we know about this person when we approved that limit. Was this beneficiary already on file when the transfer was authorised. At the point the account was reactivated, what was the standing risk rating.

Keeping the customer as a sequence of states — each with the window over which it was believed true, and the source that asserted it — costs storage and a more careful set of joins. It is also the whole difference between an institution that can explain a past decision and one that can only describe its current beliefs. A regulator, an auditor and an aggrieved customer all ask the question in the same tense.

How this gets built in practice

Where the discipline is mature, resolution is somebody's job. A team owns the customer entity as a product: one resolution service that other systems call rather than each maintaining its own joins, a defined precedence when sources disagree, re-verification that runs on a cycle instead of as an exception, and a published contract so a downstream team can tell whether it is reading the owned entity or a private copy of it.

The prevailing pattern in Pakistan and comparable markets differs for structural reasons rather than anyone's inattention. Customer due diligence arrives as a regulatory deliverable with a deadline and an auditor attached, so it gets built to be proved — a complete, retrievable file per customer — rather than to be joined to anything, and file completeness is the measure reported upward. The analytics warehouse arrives later, after the operational systems already exist, commissioned to produce reports; it therefore inherits whatever keys those systems chose and models the customer as a dimension in service of a report rather than as the entity the business transacts with. And a national identity number is a genuinely strong key, stronger than what is available in many markets, which quietly removes the pressure that would otherwise force the resolution question into the open. Holding a good key gets mistaken for having done the work.

Each of those decisions is defensible on its own. Together they produce an institution that can prove it identified a customer and cannot say, across its own systems, who that customer now is.

Before the next dashboard

Take one plain question about a single customer — are these two accounts the same person, or what did we know about this customer at the moment we raised their limit — and trace it. Which system would you answer it from. Whether the other systems would agree. Whether you could answer it as it stood last quarter rather than as it stands today.

Where that breaks down, the gap is almost never in reporting, and another dashboard will not close it. It is that no team owns the customer as an entity, with a resolution rule, a precedence order and a history. That is a modelling and ownership decision, and it is far cheaper made deliberately and early than retrofitted underneath reports people have already started to trust.