Real-Time Entity Resolution Architecture: How to Integrate the API Into a Bank's Existing Stack

TL;DR: A bank integrates real-time entity resolution through three distinct call patterns: a synchronous decision-time query inside a transaction, an event-driven re-resolution triggered by an upstream data change, and an AI-agent retrieval call. Each has its own latency budget and retry design. We expose all three through one GraphQL API, whichever pattern a given workflow needs.

Book a Demo · Try Tilores Studio (Free)

On this page

1. Which integration pattern does a bank actually need?
2. Where does the API sit against the existing banking stack?
3. How does source data map into the resolved entity?
4. What latency budget does a synchronous decision-time call need?
5. How does event-driven re-resolution keep a customer record current?
6. How does an AI agent retrieve a resolved profile?
7. When is direct API integration not the right next step?
8. Frequently asked questions
9. Sources

An API diagram is not yet an integration plan for a bank. The same entity-resolution capability may need to support an immediate transaction decision, a re-resolution after an upstream data change, or retrieval by an AI agent, and each path carries different timing and recovery constraints.

The bank therefore needs to decide where the GraphQL call sits in the existing stack and what happens when it is delayed, retried or challenged. Authentication, data mapping, event handling, observability and deployment ownership turn the API from a technical endpoint into an operating design that teams can test before relying on it.

Which integration pattern does a bank actually need?

Most integration conversations start with one question: how do we call the API? That question is premature. A bank first has to name which of three patterns the workflow needs, because each one has a different place in the stack, a different latency budget and a different failure mode.

A synchronous decision-time query sits inside a transaction: account opening, a payment release, a case-management lookup. The caller waits for the resolved answer before it can proceed. An event-driven re-resolution runs after the fact: a core banking update, a new document, a corrected address arrives, and the entity needs re-checking without anyone waiting on it. An AI-agent retrieval call sits inside a conversational or agentic flow, where a model needs the resolved customer profile before it can answer or act.

All three reach the same resolved data. We run one GraphQL API across every deployment model, so the pattern a bank chooses is an application-architecture decision, not a vendor-capability one. The table below sets out where each pattern sits before the later sections work through the budget and design detail for each.

Pattern	Where it sits	Typical trigger	Latency budget	Retry design needed	Example banking workflow
Synchronous decision-time query	Inside a transaction, blocking the next step	User action: account opening, payment release, case lookup	Tight; shares the transaction’s own SLA	Idempotent call with a client-supplied request ID; a circuit breaker for a slow or failing dependency	Resolving the applicant before an onboarding decision is returned
Event-driven re-resolution	Outside the transaction, triggered by a change	Upstream update: new document, corrected field, new source record	Loose; can queue and retry without a waiting user	At-least-once delivery with idempotent processing; dead-letter handling for repeated failures	Re-checking a customer’s resolved identity after a KYC refresh document lands
AI-agent retrieval	Inside a model’s context-building step	An agent or assistant needs the current resolved profile before acting	Tight, shares the model’s own response budget	Idempotent read; the agent should not act twice on one resolved fact	An assistant confirming a customer’s verified details before completing a request

Where does the API sit against the existing banking stack?

We separate the matching engine from the infrastructure underneath it. Every deployment model, a bank’s own AWS account, another cloud, on-premise, or our managed AWS service, runs on the same three generic components: a key-value store, a message queue and object storage. There is no proprietary database and no vendor-specific runtime, so the same GraphQL API, matching rules, audit trails and compliance features are identical wherever the deployment sits.

That separation is what makes the three integration patterns portable. A bank does not redesign its synchronous call, its event handler or its agent retrieval step if it later moves from a managed cloud deployment to its own AWS account or an on-premise environment. Our guide to infrastructure-agnostic deployment covers that choice in full. Take the deployment decision as settled, and look instead at what the application layer does with the API once it is live.

Internally, we run a three-step pipeline: extract and transform, match and resolve, then search and insights. The first step maps a bank’s own schema, normalises fields such as names, phone numbers and addresses, and enriches the record before matching runs. The second step applies deterministic, fuzzy and probabilistic matching to produce a resolved entity with explainable edges. The third step exposes ranked search, cross-source aggregation and what-if analysis through the same GraphQL surface. An integration only has to call into the third step; the first two run inside our pipeline.

How does source data map into the resolved entity?

An integration fails less often because the API is hard to call and more often because the mapping from source fields to the entity graph was never designed. Each field type behaves differently once it reaches the match step, and the integration should be built with that in mind instead of treating every column as interchangeable text.

Source field type	What normalisation does before matching	Integration implication
Name	Canonicalises casing and spacing; feeds deterministic, fuzzy and phonetic comparison	Send the original readable value; do not pre-truncate or pre-hash it in the client before the call
Phone number	Normalised to E.164 format	Send the raw entered value where possible; let normalisation run inside the pipeline instead of duplicating a parser client-side
Address	Component parsing and canonical form	Send structured components if the source system already has them; a single free-text field still works but loses some parsing precision
Internal or account ID	Kept as a stable deterministic key	Use this field for the idempotent request key wherever the source system already guarantees uniqueness

Get this mapping wrong and the integration still runs, it just resolves less accurately, which shows up later as a review-queue or false-merge problem, not an integration error. Map the fields before writing the call, not after the first production incident.

What latency budget does a synchronous decision-time call need?

A synchronous call borrows from the transaction’s own time budget, so the integration has to know what is left once the other steps in that transaction are accounted for. The figures below are illustrative, labelled assumptions for a hypothetical account-opening flow, not a real bank’s measured SLA.

An illustrative 2,000ms account-opening decision budget, split across the other checks in the transaction, with room left for identity resolution.

1. Set the total decision budget. Assume the bank sets a 2,000ms budget for the whole account-opening decision, end to end.
2. Subtract the other steps in the transaction. Assume sanctions, PEP and adverse-media screening takes 400ms, a fraud score takes 300ms and the core banking write takes 200ms. Together that leaves 1,100ms.
3. Place the identity-resolution call against what remains. Our managed-AWS call at roughly 150ms uses about 14% of that remaining budget. A self-hosted call at roughly 1ms uses effectively none of it, which matters most when the transaction already has thin headroom.
4. Design the call to survive a retry inside that budget. A synchronous call needs a client-supplied request identifier so a retry after a timeout does not create a duplicate resolution attempt. The Amazon Builders’ Library describes an idempotent operation as one that “can be retransmitted or retried with no additional side effects,” which is the property a synchronous decision-time call needs when it shares a tight budget with everything else in the transaction.
5. Protect the transaction from a slow dependency. Martin Fowler’s description of the circuit breaker pattern is the standard answer to a remote call that “can fail, or hang without a response until some timeout limit is reached.” Wrap the identity-resolution call the same way you would wrap any other remote dependency in the transaction, so one slow call does not stall the whole decision.

Sanctions, PEP and adverse-media screening belongs inside this same synchronous step for account opening and similar onboarding decisions. OpenSanctions’ PEP dataset covers roughly 1.96 million entities, including about 717,580 individual PEP targets across 264 countries, queryable through its own API. The FCA’s review of customer due diligence practice found that firms distinguish standard from enhanced due diligence under a risk-based approach, with dedicated control frameworks for identifying PEPs. Resolving the customer correctly before that screening step runs is what keeps the screening result attached to the right person, not a near-duplicate record.

Banks already answer to hard deadlines like this elsewhere in the stack. The European Parliament’s summary of the EU Instant Payments Regulation states that “the money must arrive into the recipient’s account within ten seconds” and that a transfer is “supposed to be executed regardless of the day or hour.” A synchronous identity check inside a workflow bound by a deadline like that has no room to treat latency as a detail to fix later.

How does event-driven re-resolution keep a customer record current?

A customer record does not stay resolved forever. A new source system comes online, a document correction arrives, or an existing record is edited, and the entity needs re-checking without a user waiting on the result. That is a different design problem from the synchronous call.

An event-driven integration listens for the upstream change, queues a re-resolution request and processes it against the same GraphQL API used by the synchronous pattern. Because nothing is waiting on the result, the latency budget is loose, but the delivery guarantee matters more. A message queue that guarantees at-least-once delivery can redeliver the same event, so the handler still needs the same idempotent design as the synchronous call, keyed on the source event or record ID instead of a fresh request ID each time.

Failures need a defined path, not a silent drop. A dead-letter queue for repeatedly failing re-resolution events, reviewed on a schedule, keeps a stuck record from staying stale unnoticed. This pattern is also where a bank’s normalisation choices from the schema-mapping section compound: if a field was mapped inconsistently at first ingestion, every later re-resolution event repeats that inconsistency until the mapping is fixed at the source.

How does an AI agent retrieve a resolved profile?

An AI agent or assistant that needs to confirm or act on a customer’s details is making a third kind of call: a retrieval that has to complete inside the model’s own response budget, using data the agent should treat as ground truth, not something it can guess from surrounding text.

Our IdentityRAG connects to LangChain and Amazon Bedrock so an LLM retrieves a unified customer profile before generating a response, at the same sub-150ms identity-resolution latency as the other patterns. The design requirement here is closer to the synchronous pattern than the event-driven one: the call still needs an idempotent read, so an agent that retries a retrieval does not act twice on one resolved fact, and the call still needs a budget check against the model’s own latency target.

We also publish an MCP server, which helps an assistant design a configuration or generate a GraphQL query. It does not itself perform live resolution; the query it generates still runs against our GraphQL API. Keep that boundary clear when designing an agent integration: the MCP server is a design-time aid, the GraphQL API is the runtime path all three patterns above ultimately call.

The protocol behind that MCP server treats retry safety as something a tool call must earn, not assume by default. The Model Context Protocol’s own guidance on tool annotations frames its idempotentHint around one question, “Can you safely call it again with the same arguments?”, and only a hint of true tells a client that a failed call is “safe to retry on failure.” A resolution call exposed to an agent needs that same answer, and the same client-supplied identifier and idempotent design as the synchronous and event-driven patterns above.

When is direct API integration not the right next step?

Wiring any of these three patterns into production before the matching design is settled is the wrong order of work. If a bank has not yet run a bounded proof of concept, does not have a labelled truth set, and has not decided its confidence threshold, integration effort spent now will need to be redone once those answers change the mapping or the workload.

Our guide to PoC inputs a bank needs sets out what that groundwork looks like, and our guide to precision and recall explains why the confidence threshold is a deliberate trade-off, not a default setting. A team that has not done that work yet is better served starting in Tilores Studio, which runs entity resolution locally against up to 100,000 records with no signup beyond an email and no data leaving the machine, than by writing production integration code against an unsettled matching design.

Frequently asked questions

Does Tilores support calling it without GraphQL?

No. We expose one GraphQL API across every deployment model and every integration pattern described here. An MCP server helps an assistant design a configuration or generate a GraphQL query, but the query still runs against our GraphQL API.

Do the three integration patterns need three different API calls?

They call the same GraphQL API and the same resolved entity, but each pattern needs its own transport, latency budget and retry design around that call: a blocking call inside a transaction, a queued handler for events, and a model-side retrieval for an agent.

What latency should an integration plan for?

Our published figures are around 150ms on managed AWS and around 1ms self-hosted. Treat these as the identity-resolution portion of a larger transaction budget, not the whole budget; the earlier worked example shows how to size the remaining steps around it.

Does moving deployment model, for example from managed AWS to a bank’s own AWS account, change the integration code?

No. The GraphQL API, matching rules, audit trails and compliance features are identical across our deployment models, because the matching engine sits on the same three generic infrastructure components in every case. The integration layer calls the same API regardless of where the deployment runs.

Sources

1. Tilores Product: Entity Resolution Infrastructure, Tilores.
2. Tilores Deployment Options, Tilores.
3. Tilores Studio: Download the Free Evaluation, Tilores.
4. Infrastructure-Agnostic Entity Resolution, Tilores.
5. Entity Resolution Proof of Concept: 7 PoC Inputs a Bank Needs in 2026, Tilores.
6. Precision and Recall in Entity Resolution, Tilores.
7. Making Retries Safe with Idempotent APIs, Amazon Builders’ Library.
8. CircuitBreaker, Martin Fowler.
9. Politically Exposed Persons Dataset, OpenSanctions.
10. Firms’ Customer Due Diligence Processes and Controls: Our Findings, Financial Conduct Authority.
11. Ensuring Euro Money Transfers Arrive Within Ten Seconds, European Parliament.
12. Tool Annotations as Risk Vocabulary: What Hints Can and Can’t Do, Model Context Protocol.