In many banks, the concept of a customer is defined separately in every system. The core banking system has one customer number, the card system another, the lending system a third and the digital channels a fourth. A single individual may be recorded in three systems with three spellings of their name, two outdated addresses and one telephone number nobody answers any more. As long as each system works in isolation, this fragmentation stays hidden. The moment the bank wants a unified view, a risk analysis or a personalised service, the problem surfaces.
The importance goes well beyond data hygiene. Knowing the customer correctly is the foundation for customer-identification obligations, credit-risk management, fraud prevention and even an honest calculation of profitability. If the bank cannot say that three accounts, two cards and one loan belong to the same person, it can neither measure that person's aggregate exposure nor deliver a coherent experience across branch and app. Legal entities and the relationships between them, such as shareholding, representation and guarantees, add a further layer that a flat customer table simply cannot model.
The architectural answer is a single source of truth for the party, known in the technical literature as party master data. In this model, natural persons, legal entities and even intermediate roles such as attorneys or beneficiaries all sit under the general concept of a party, and the relationships between them are stored explicitly. The master system holds the golden identity of each party, maps the local identifiers of every other system onto it, and publishes changes to all consumers through APIs and events. Operational systems keep their own data, but they are no longer the source of truth.
The first practical consideration is the matching and merging rules. Deciding that two records belong to the same person combines deterministic rules, such as a national identifier or registration number, with probabilistic ones, such as similarity of name and date of birth. These rules must be transparent, tunable and reviewable, because every wrong merge can link two people's accounts together. For example, when two records share a similar name and the same date of birth but different addresses, the system should flag them for human review rather than merge them automatically.
The second consideration is modelling relationships. In corporate banking, the real value comes from understanding the network: which companies belong to a holding group, who holds signing authority, which person guarantees which facility. These relationships need a type, a start and end date and a recorded source, so that they can be both queried and audited. A good model lets the bank ask what the total exposure to a given economic group is and receive a single coherent answer instead of a spreadsheet stitched together by hand.
The usual pitfalls in party master data projects are recognisable. First, trying to migrate every system at once, which turns the project into a multi-year programme with no intermediate results. Second, neglecting data ownership; if no business unit is accountable for the quality of each attribute, the master data becomes polluted again within months. Third, building the master without APIs and events, so that other systems end up receiving data through nightly files. Fourth, ignoring history; a bank must be able to reconstruct what it knew about a party on a specific date in the past.
Niadad's Ashna platform («آشنا») is designed for exactly this role: unified management of natural and legal persons, the relationships between them, configurable matching rules and publication of changes through APIs and events. In Niadad's banking programme, Ashna sits as the party master alongside the identity layer and the API gateway, so that operational systems, digital channels and analytics all work from one shared definition of who the customer is.
Party master data is not the most glamorous project a bank can run, but it is the prerequisite for almost every glamorous one. Without it, AI trains on wrong data, the customer 360 view stays incomplete and risk management leans on guesswork. With it, every subsequent project starts from solid ground. The sooner a bank treats party data as shared infrastructure rather than a departmental concern, the sooner the rest of its roadmap becomes achievable.