Real-Time Identity Resolution Under GDPR: How Regulated Institutions Do It (2026)
TL;DR: Real-time identity resolution under GDPR means resolving records at ingestion, retaining lineage and policy evidence, and retrieving the current resolved context when a regulated workflow queries it. The compliance work is not the match alone: define lawful basis, minimise attributes, control residency and transfers, honour deletion rules, and keep a clear audit trail.
How do regulated institutions handle real-time identity resolution under GDPR?
They treat real-time identity resolution as controlled personal-data processing, not as a shortcut around GDPR. The practical pattern is simple: resolve the entity when records are ingested, preserve the source-record lineage and match evidence, and let operational systems retrieve the current resolved context at query time.
This matters because regulated workflows rarely wait for overnight cleansing. A sanctions check, a customer-risk refresh, a call-centre query or a credit decision may need the latest known entity view immediately. Tilores describes this pattern as ingesting customer data from multiple sources, resolving duplicates in real time, and returning unified entity profiles through query interfaces such as GraphQL. The Tilores matcher documentation also supports deterministic matching, fuzzy matching and probabilistic matching, so the rules can use exact identifiers where they exist and similarity scoring where messy real-world data requires it.
GDPR changes how that architecture is governed. It does not ban identity resolution. It requires a lawful basis, purpose clarity, data minimisation, security controls, retention discipline and accountability. Tilores should therefore sit inside a governed data estate, connected to KYC, AML, customer-service, MDM, CDP and warehouse systems, with each downstream use mapped to a purpose and control set.
What GDPR requirements should the architecture satisfy first?
The first design task is to turn GDPR principles into system responsibilities. The table below is not legal advice, but it is the checklist I would want a delivery team to walk through before moving real-time resolution into a regulated workflow.
| Control area | GDPR anchor | What the resolution layer must prove |
|---|---|---|
| Lawful basis and purpose | Article 6 | The processing purpose, lawful basis, source systems and downstream consumers are documented before data is matched. |
| Minimisation and storage limitation | Article 5 | The model uses only attributes needed for the use case and applies retention rules to records, evidence and derived entity context. |
| Privacy by design and default | Article 25 | Access, lineage, deletion and default-minimum exposure are designed before the workflow goes live. |
| Processor governance | Article 28 | The controller and processor roles are clear, including hosting model, access rights and operational responsibilities. |
| Residency and transfers | Article 44 and Article 45 | The team knows where personal data is stored and whether any transfer outside the permitted environment occurs. |
| Accountability and security | Article 30 and Article 32 | Records of processing, query logs, access controls and deletion actions can be reconstructed during audit or incident review. |
How should data residency be handled?
GDPR is not only a location rule, but residency still becomes a practical control because Chapter V governs transfers of personal data to third countries or international organisations. If a bank, insurer, fintech or bureau has a policy that personal data must remain in a defined cloud account, region or VPC, the identity-resolution layer has to respect that boundary.
Tilores is useful here because it can be deployed either in Tilores-managed infrastructure or inside a customer AWS account. The Tilores data-compliance page says the customer-account model can keep data inside the customer VPC with Tilores having no access, while still supporting audit trails, access controls and automated deletion tooling. That is the right shape for institutions that want the resolution engine close to their operational systems without moving personal data into an uncontrolled shared environment.
The residency decision should be made before match rules are tuned. Once records flow into a resolution layer, the team needs to know whether source attributes, match edges, entity identifiers, query logs and deletion evidence all remain inside the same governed boundary.
How do lawful basis and processing purpose affect matching?
Entity resolution cannot create a lawful basis for processing. Article 6 requires the organisation to identify the basis for the processing in the first place. A KYC refresh, fraud investigation, customer-service lookup and marketing merge are different purposes, and they should not inherit controls from each other by accident.
The safest operating model is to define the purpose, then decide which attributes are needed for matching. For regulated financial-services use cases, exact identifiers may be appropriate where they are available, but real data also contains typos, name variations, address changes and partial dates. That is why a resolution layer needs deterministic matching for hard identifiers and probabilistic or fuzzy matching for records where confidence must be scored rather than assumed.
Tilores already describes both deterministic rule-based matching and probabilistic matching in its public product and matcher documentation. In a GDPR-governed workflow, those capabilities need to be paired with documented processing purposes, match thresholds, access rules and retention policies.
How do minimisation, retention and deletion work with resolved entities?
Real-time resolution does not mean keeping every attribute forever. Article 5 includes data minimisation and storage limitation, so the system should separate the current entity view from the source evidence and from any old attributes that no longer serve the purpose.
A practical design keeps the entity useful without turning it into an unmanaged archive. Store the source-record links needed to explain why records were assembled. Keep the match scores, rules or edges needed to support audit and correction. Avoid copying extra fields into the resolved view just because they are present upstream. Where retention rules require deletion, expire both source-derived attributes and any resolved context that depends on them.
Article 17 also matters because a valid erasure request may require deletion to propagate through connected records and derived views. Our compliance controls include data provenance, cascading deletions and automated deletion tools. The Tilores API documentation also exposes entity and entity-by-record queries, which is important operationally because a team must be able to find the resolved entity affected by a specific source record before it can correct or delete the right information.
What should the audit trail prove?
The audit trail should prove how the entity was assembled, who used it, and what changed over time. Article 30 points to records of processing activities, and Article 32 addresses security of processing. In real-time identity resolution, those obligations translate into concrete evidence.
For each regulated workflow, the organisation should be able to show the source systems, key fields used for matching, match policy, confidence evidence, query requester, export destination, access-control decision and deletion or correction action. Our data-compliance controls log queries, exports and deletions, and our product page documents a full audit trail for retrieved entity graphs. That evidence is what lets a compliance or operations team explain the workflow later without reverse-engineering it from warehouse tables.
The important point is not that every user should see every piece of evidence. It is that the evidence exists, is restricted by role, and can be reconstructed during audit, DSAR response, model review or incident investigation.
Where does sanctions, PEP and adverse-media screening fit?
Resolve the entity cleanly first, then screen the current context against the appropriate sanctions, PEP and adverse-media data. If the same person appears under three spellings across onboarding, transactions and servicing, screening each spelling in isolation increases the chance of both missed risk and avoidable false positives.
OpenSanctions is one example of a public source for sanctions, PEP and adverse-media risk data. The identity-resolution layer should not be treated as a screening engine or as a replacement for case management. It should assemble the person or organisation context that the screening process needs, preserve the evidence behind that assembly, and make it available to the AML or KYC workflow at the moment of review.
This is the same architecture Tilores discusses in its real-time AML and KYC article and in its perpetual KYC content: customer context has to stay current enough for ongoing monitoring, not just for the onboarding snapshot.
Where should Tilores sit next to MDM, CDP, KYC and warehouse systems?
Tilores should sit next to MDM, CDP, KYC, AML and warehouse systems. It should not be positioned as a replacement for those systems. MDM may remain the governance record for mastered domains. A CDP may remain the activation layer for approved customer engagement. A KYC or AML platform may remain the workflow and case-management layer. The warehouse may remain the analytical store.
The role of Tilores is narrower and more operational: resolve and assemble entity context as records arrive, then let authorised systems query the current resolved view when they need it. That pattern is why the entity-resolution guide for KYC and customer 360, the credit-bureau article and the AML article all point to a similar operating principle. The faster the institution can resolve the right person or organisation, the faster the downstream workflow can act on accurate context.
That is also why product truth matters. Matching is not only deterministic. It is deterministic where identifiers are strong, probabilistic or fuzzy where data is messy, and governed by policy where a regulated institution needs to explain what happened.
FAQ
Does GDPR prevent real-time identity resolution?
No. GDPR does not ban real-time identity resolution. It requires a lawful basis, purpose clarity, minimisation, security, retention discipline and accountability for the personal-data processing involved.
When should the entity be resolved?
For operational workflows, resolve and assemble the entity at ingestion, then retrieve the current resolved context at query time. That avoids waiting for batch cleansing when sanctions screening, KYC refreshes or service decisions need current context.
Does Tilores replace MDM, CDP or KYC systems?
No. Tilores should sit next to MDM, CDP, KYC, AML and warehouse systems. It provides a real-time resolution layer so those systems can work with current entity context.
How do erasure requests work when records are resolved?
A valid erasure request should be traced from the source record to the affected resolved entity and any derived context. The resolution layer needs provenance, deletion propagation and an audit record showing what was removed.
Where does sanctions and PEP screening fit?
Screening should run after the person or organisation has been resolved cleanly enough for the workflow. The resolution layer assembles context and evidence; the screening and case-management systems make and manage the risk decision.
See what resolved entity data does for your business — and your AI.