How to Resolve One Bank Customer Across Core Banking, CRM and Card Systems
TL;DR: Treat identity as a reversible link among source records, not as a replacement system of record. Give core banking, CRM and card systems separate keys and field owners. Test cardholder and account-holder relationships, late changes, false merges and split recovery on bank-defined records before choosing a resolver.
Book a Demo · Try Tilores Studio (Free)
On this page
- What should the identity layer decide?
- What must each source provide?
- How does one difficult customer resolve?
- What happens when records change?
- Which tests decide the shortlist?
- How should a bank choose the tool?
- Frequently asked questions
What should the identity layer decide?
It should answer a narrow, consequential question: which source records refer to the same person or organisation, and what evidence supports that link? It should return the source IDs, relationship type, link status and a way to explain or reverse the decision. It should not become the authority for an account balance, card transaction, contact permission or screening outcome simply because it can connect those records.
Our financial-services page describes an identity view across core banking, CRM and support. That is a useful starting point, but it does not by itself prove a particular card-system integration, change latency or operating control at your bank. Make the card feed and every downstream use part of the evaluation contract.
Start with the reader’s output, not a vendor diagram: a service agent may need the current CRM contact tied to a core customer; a fraud investigator may need the relationship between an account holder and a supplementary cardholder. Those are different views of the same evidence. Keep sanctions, PEP and adverse-media screening as separate decisions owned by their respective teams. A person link can supply context to them; it is not a screening clearance.
What must core banking, CRM and the card system each provide?
Agree this matrix with the source owners before procurement. The example keys below are illustrative, not claims about a particular bank’s schema. Each owner should replace them with a stable, permitted source key, an explicit update path and a measurable test target.
A three-system identity contract to fill with bank-owned values
| Source and stable key | Authority and relationship | Change path and test target | Identity output and owner |
|---|---|---|---|
Core banking: core_party_id; separate account_id | Core owner defines party status and who holds each account. Account ownership is a relationship, not proof that two people are one. | New party, corrected party and account-holder change. Record the source event time, receipt time and the bank’s acceptable link-update delay. | Return linked party IDs and account-holder edges to authorised consumers. Core owner resolves disputed party or account facts. |
CRM: crm_contact_id | CRM owner defines contact attributes and the bank’s permission rules. A shared telephone or address is evidence to weigh, not an automatic merge key. | Create, correction and deletion/permission change. Test whether changed evidence re-evaluates a link and when consumers see it. | Return the contact-to-party link with provenance. CRM owner decides which contact field may be disclosed. |
Card platform: card_customer_id and cardholder_id; separate card/account references | Card owner distinguishes a cardholder from the person liable for the underlying account. Never substitute a card number for a person identity key. | Issue, supplementary-holder change, late event and closure. Test event ordering and the bank’s permitted card relationship exposure. | Return person-to-cardholder and cardholder-to-account relationships separately. Card owner resolves disputed card facts. |
That separation matters when one account has several people attached to it. The deeper question of one customer across legal entities also needs its own boundary; an entity relationship is not a licence to collapse distinct people. For any link reused in risk reporting, the Basel Committee’s risk-data principles make accuracy, completeness and timeliness useful downstream checks. They do not turn this example matrix into a universal regulatory specification.
Keep source keys and event history, distinguish a verified link from an unresolved case, and send uncertain matches to human review. The illustration is conceptual, not a product screen.
New posts on entity resolution, identity data and AI. No spam, unsubscribe any time.
How does one difficult customer resolve?
Use a deliberately awkward, fictional case. Core record C-104 says Alex Morgan holds account A-17. CRM record R-88 says Aleks Morgan, with a recently changed address and a service telephone shared with a family member. The card platform has cardholder H-52 for Alex and supplementary cardholder H-53 for Jamie Morgan, both associated with A-17. None of these IDs represents a real customer.
The proposed link is C-104 ↔ R-88 ↔ H-52, with the conflicting address retained as evidence for review. H-53 stays a separate person linked to the same account by a supplementary-cardholder relationship. If the match evidence is insufficient, the system returns “unresolved” to a human queue; it must not quietly merge Jamie into Alex. The output records the rule or review decision, the source event versions and the consuming systems that received the link.
This is the line a shortlist demo must cross. A polished screen that shows “one customer” but cannot expose the source IDs, the relationship type or the reversal path has not answered the bank architect’s question. Equally, a tool should not push a corrected CRM address into core banking merely because it recognised the person. Source owners still approve field changes.
What happens when a late event, correction or mistaken merge arrives?
Run the three events in sequence. First, a card event arrives late, after a newer account-holder change. The connector must preserve the source event time and processing time so it does not overwrite the newer relationship by arrival order alone. Second, CRM corrects Aleks’s address. Re-evaluate links that used the old address, but retain the previous decision and its evidence for audit. Third, a reviewer finds that an earlier link between Alex and another Morgan was a false merge. Split the identity graph, publish a new link version and identify every consumer that needs a refresh or a correction.
Write the return path into the contract: can the card platform and CRM acknowledge a link-version change, and can a downstream service reject a stale one? The FCA’s operational-resilience observations ask UK firms in scope to map the people, processes, technology and information behind important business services. If this identity output supports one of those services, map the replay and fallback dependency there; do not imply that every identity link is itself an important business service.
Keep the data sent to each consumer proportionate. The European Data Protection Board’s overview identifies purpose limitation, data minimisation and accuracy among the core personal-data principles. In practical terms, a service desk may need the fact that two permitted records are linked, not every card or compliance attribute used to reach that decision. Have the bank’s privacy and security owners approve the attribute and permission design.
Which acceptance tests should decide the shortlist?
Use the same bank-defined, synthetic or properly authorised records with every contender. Do not accept a single aggregate match score as a substitute for the failure cases below. The expected evidence should include source IDs and versions, link explanation, operation log, human decision where required and the downstream acknowledgement. Latency targets belong to the bank and each consuming workflow, not to an unsourced product promise.
Cross-system acceptance tests, evidence and accountable owner
| Test | Expected result | Evidence and owner |
|---|---|---|
| False merge | Alex and Jamie stay separate people despite a shared account or address. | Link explanation and negative case; identity owner signs off. |
| Missed link | Approved Alex/Aleks variants link or enter a review queue rather than silently disappear. | Candidate evidence and reviewer disposition; identity owner. |
| Changed record | A corrected CRM field triggers re-evaluation without erasing the prior decision. | Before/after versions and consumer update; CRM owner. |
| Late event | Older card input cannot override a newer relationship solely by arrival order. | Event and receipt times, replay log; card owner. |
| Split | A mistaken link can be reversed, with impacted consumers identified and refreshed. | Split decision, new link version and acknowledgements; identity and consumer owners. |
| Idempotent replay | Replaying the same source event does not create a second person or duplicate edge. | Event key and before/after graph; integration owner. |
| Permission boundary | An unauthorised consumer cannot read card or screening details through an identity lookup. | Denied request and access log; security/privacy owners. |
| Stale read | A consumer recognises an old link version and follows the bank’s fallback rule. | Version comparison, alert and recovery time; service owner. |
These tests make “real time” a question the team can answer. Specify which event starts the clock, which consumer must be current, the tolerated delay, the alert threshold and the fallback when a feed stops. Test each change path separately; a fast initial bulk match does not prove a fast correction or split.
How should a bank choose the tool?
Shortlist against the contract, not against a feature grid. Ask each vendor to ingest the same authorised core, CRM and card-shaped records; show its source adapters and allowed attributes; explain every proposed link; replay a late event; split a false merge; and show exactly what the downstream systems receive. Score the demonstration on evidence returned, change handling, reversibility, permission boundaries and who operates each component. Cost and deployment matter, but neither can compensate for an unexplainable customer link.
Tilores can be evaluated as an identity layer for financial-services records; our financial-services overview describes core-banking and CRM unification and an audit trail. Require the card-specific adapter, the bank’s latency target and the split/replay behaviour to be demonstrated on your data rather than inferred from that page. If the programme also spans companies or beneficial owners, keep that entity work distinct from person and cardholder links.
The decision pack should be small enough to use: this matrix with named owners, the fictional edge-case walkthrough, a bank-approved test dataset, a pass/fail record for each test, open exceptions, operating responsibility and a stop path. If a contender cannot preserve a distinct supplementary cardholder or cannot reverse a mistaken merge without manual reconstruction, record the failure before a wider rollout. That is a more useful procurement outcome than a dashboard screenshot.
Test the contract on your own records. Book a Demo to walk through the three-system boundary, or Try Tilores Studio (Free) and run the acceptance cases with your bank’s owners.
Frequently asked questions
Is a card number a good cross-system person key?
No. Use a bank-governed person or cardholder source ID and model the card and account as related objects. In the test contract, a card reference may help locate a relationship, but it must not make a supplementary cardholder the same person as the account holder.
Who owns the “merged customer” after resolution?
No single system acquires all field authority. The identity layer owns its link decision and evidence; core, CRM and card owners keep their source facts and permissions. A downstream customer view should say where each value came from and when the link was decided.
How quickly must a corrected record change the link?
Set the target per workflow. Define the source event, the consumer that needs the update, its permitted delay and its fallback on a stale link. Test corrections and splits separately from first-time matching; no general vendor latency claim answers those questions for your bank.
Can the same link be used for sanctions, PEP and adverse-media work?
It can be proposed as identity context, but screening remains a separate controlled decision. The screening owner must test permissible data, false matches, review steps and audit evidence for each workflow. Do not treat a resolved person link as a sanctions or PEP clearance.
Sources
See what resolved entity data does for your business — and your AI.