Can a Bank Run Entity Resolution in Its Own Cloud Account in 2026? A Procurement Control Checklist

TL;DR: Yes. A bank can run entity resolution in its own cloud account when it can evidence who controls encryption keys, audit logs, access, change and exit. Account ownership creates a useful boundary, but the procurement decision also needs a tested responsibility model, resilience evidence and matching controls that the bank can inspect.

Book a Demo · Try Tilores Studio (Free)

On this page

1. Does deployment in the bank’s account settle the control question?
2. Which evidence should procurement require?
3. How should the bank assess the evidence?
4. What should the proof of concept prove?
5. What should the final decision record contain?
6. Evaluate the control model with your own requirements
7. Frequently asked questions
8. Sources

For a bank buyer, an offer to run entity resolution inside the bank’s own cloud account can sound like the control question is already settled. The data and infrastructure stay in a familiar boundary, while the matching service supports the same customer, financial-crime and operational decisions that make the workload important.

That boundary is only the start of the control case. Key custody, access, logging, change control, resilience and exit rights still need evidence that a security, procurement and legal review can inspect. The decision therefore depends on how the architecture, operating model and contract assign those responsibilities, and on whether the bank can test the result before production.

Does deployment in the bank’s account settle the control question?

No. It changes the control boundary, which can be valuable, but it does not replace procurement, security, privacy, resilience or legal review. The sharper procurement question is not where the software runs. It is who holds the encryption keys, who owns the audit logs, and what the bank can prove about its exit rights if the relationship ends.

We can run inside a bank’s own AWS account, using DynamoDB, SQS and S3 in its VPC. The bank can therefore keep the infrastructure and data inside its chosen account and region. Inside that same account, the bank can create AWS KMS customer managed keys that it creates, owns and exclusively controls, and configure where its own CloudTrail trail delivers its audit log files. The bank owns the infrastructure; we manage and update the deployment remotely, and our staff cannot access customer records. That is a strong architectural starting point for a regulated workload because the bank can apply its established key-management, network, logging and resource-governance patterns. For how the same engine maps onto AWS, another cloud or an on-premise estate, see Infrastructure-Agnostic Entity Resolution: Running Tilores on AWS, Another Cloud, or Your Own Hardware.

The documented split still needs an enforceable responsibility matrix. Which party can assume which IAM role, and which party can use which key? What metadata or logs, if any, can support personnel access, and who controls their retention? Which actions require the bank’s approval? What happens when an update fails? A diagram that stops at the account boundary cannot answer those questions.

AWS describes security and compliance as a shared responsibility between AWS and the customer. Adding an entity resolution supplier creates another allocation of duties inside that model. Procurement should insist on a responsibility matrix that names the bank, Tilores and AWS against every material control, including key ownership and log custody. An unassigned control is not inherited merely because the software runs in the bank’s account.

The product evidence should also be precise. Production applications query us entirely through GraphQL. The matching pipeline uses deterministic, fuzzy and probabilistic methods as three distinct techniques. We normalise and persist data for matching while retaining original records. Those facts affect network design, data mapping, model governance, testing and the evidence a reviewer should expect.

Which evidence should procurement require?

Use the following table as an admission checklist. A verbal assurance or a slide should not pass a control unless the bank can inspect a durable artefact, reproduce the result or bind the promise contractually.

Control question	Evidence to request	Acceptance test	Failure signal
Where do records, indexes, exports, backups and logs exist, and who owns them?	Architecture and data-flow diagrams, AWS resource inventory, approved regions, backup locations, log-ownership statement and every outbound endpoint	Trace one test record from ingestion through matching, query, export, backup and deletion, and confirm the bank controls the underlying log storage	Undefined telemetry path, hidden support copy or a diagram that omits backups and log ownership
Who holds the keys and can access the environment?	IAM role catalogue, KMS key ownership and key policy, trust policies, support-access procedure, approval path, session duration and activity logs	Demonstrate denied access by default, bank-controlled key policy and one approved, time-limited support session	Standing administrator access, a key policy we can change unilaterally, shared credentials or actions that are not attributable to a person
How is customer identity resolved?	Versioned transformations, deterministic rules, fuzzy comparers, probabilistic features, thresholds and source provenance	Replay labelled match and non-match pairs, including difficult multilingual and incomplete records	One unexplained score, no source trace or no distinction between fuzzy and probabilistic matching
Can a reviewer explain one entity?	Record lineage, rule or feature evidence, confidence, configuration version and reviewer action history	Select one merge and reconstruct why each record belongs to the entity	A final entity without the evidence that formed its boundary
How are releases controlled?	Release notes, signed artefact identity, infrastructure plan, approval gates, rollback procedure and configuration migration plan	Run a non-production update, reject an unexpected infrastructure change and restore the prior version	Remote changes without approval or a rollback that covers code but not rules and data state
How is service continuity proved?	Recovery objectives, dependency map, backup and restore results, operational contacts and incident exercises	Restore a representative environment and reconcile entity counts, rules and provenance	Backups exist but have not been restored, or restored data cannot be reconciled
How can the bank leave?	Export format, deletion method, transition support, licence effects, configuration portability and evidence-retention plan	Export records, entities, provenance and configuration, then verify deletion against an agreed test scope	Data is exportable but match evidence or configuration is not
What assurance exists?	Current assurance report, scope, exceptions, remediation status and mapping to the bank’s control framework	Confirm that the service, period and controls relied upon are inside the report’s scope	A badge or certificate is presented without scope and exceptions

We have completed a SOC 2 Type I audit. Treat the report as one input to due diligence, not as a substitute for the bank’s own architecture, contract and operating-control assessment.

How should the bank assess the evidence?

Start with the workload, not the vendor. Name the business service that depends on resolved identity, the decisions it supports, the data categories involved and the harm caused by false matches, missed matches, unavailability or unauthorised access. A customer service lookup and a financial-crime investigation may use the same entity graph while requiring different thresholds, permissions and escalation paths.

Next, draw the complete control boundary. Include source systems, ingestion routes, the entity graph, GraphQL consumers, administration paths, observability, backups, export locations and the people or systems able to cross each boundary. Mark ownership beside every component. The diagram should make an unanswered question conspicuous.

DORA and EBA outsourcing guidance are European frameworks for in-scope EU banks and, where applicable, EEA banks. GDPR Article 28 applies only where the processing is covered by GDPR. DORA’s Article 2 scope turns on the type of financial entity. The EBA outsourcing guidelines apply to institutions within their stated scope. GDPR territorial scope can include controllers and processors outside the EU. A bank outside a particular regime should map the same control questions to its applicable local supervisory and privacy rules.

Then map the architecture to obligations and contractual evidence. DORA permits financial entities to contract only with ICT providers that comply with appropriate information security standards. The procurement pack should therefore connect each relied-upon control to an owner, technical proof, contractual clause, monitoring method and exit response.

For a critical or important function, do not accept an abstract right to audit. EBA outsourcing guidance says agreements for critical or important functions should provide full access to relevant systems, networks, information and data. Turn that principle into an executable procedure: who may request evidence, how quickly it must be supplied, how on-site or remote inspection works and how other customers’ confidentiality is protected.

Privacy review needs the same specificity. Do not infer controller, processor or subprocessor roles solely from who owns the AWS account. Record the actual purposes, instructions, access and processing operations, then have the bank’s legal team assign the roles. GDPR Article 28 says a processor must allow for and contribute to audits by the controller or its mandated auditor. The contract and evidence process should make that right usable.

Finally, distinguish a product control from proof that the bank operates it correctly. Every resolved record preserves source provenance. Every query, export and deletion is logged. Procurement should still ask who reviews those logs, where alerts go, how long evidence is retained and how the bank tests that logging remains complete after a change.

What should the proof of concept prove?

A useful proof of concept tests the future control model, not only match accuracy on a clean file. Use data that reflects spelling variation, transliteration, shared addresses, changed identifiers, incomplete dates, legal-entity relationships and hard non-matches. Define the expected decision for each labelled pair before running the system. For the specific inputs a bank should assemble before that test starts, see Entity Resolution Proof of Concept: 7 PoC Inputs a Bank Needs in 2026. Pair those inputs with the control evidence the PoC and procurement process should produce alongside them: key custody, log ownership and a rehearsed exit.

Measure precision and recall separately. For a bank, false positives and false negatives can create different harms, so a blended score hides the trade-off. Set threshold bands for automatic acceptance, automatic rejection and human review. Record which deterministic rule, fuzzy comparison or probabilistic evidence contributed to each result.

Include sanctions, PEP and adverse media screening in the test journeys. Entity resolution should improve the identity presented to screening and investigation tools, but it should not silently replace their risk decisions. Use a current reference source and controlled expected results. OpenSanctions documents PEP coverage. The bank should test how updates, aliases and ambiguous candidates flow into its existing review process.

The proof should also exercise operational controls. Run it through the intended AWS account structure. Apply the planned IAM roles. Send logs to the bank’s monitoring destination. Attempt prohibited access. Rotate a credential. Change a matching configuration. Restore a prior version. Export the evidence required for one challenged entity. Delete a scoped test subject and reconcile the result.

Do not let a successful demonstration erase open conditions. Record limitations, compensating controls, responsible owners and due dates. If the supplier must complete a control before production, make that condition part of the decision and contract instead of leaving it in meeting notes.

1. Define the workload and harms. State what the resolved identity supports and the consequences of error, delay and unauthorised access.
2. Map the full control boundary. Include data, identities, administration, logs, backups, exports and human access.
3. Collect durable evidence. Require technical artefacts, reproducible tests, assurance scope and contractual commitments.
4. Run a controlled proof. Test matching quality, explainability, access, monitoring, change, recovery and deletion in the proposed environment.
5. Record the decision and residual risk. Name every condition, owner, deadline, monitoring measure and exit trigger.

Five separate evidence streams, not one vendor assurance, should feed the final procurement decision.

What should the final decision record contain?

The decision record should be short enough to use and complete enough to challenge. It should identify the approved workload, deployment pattern, AWS accounts and regions, data classes, interfaces, support-access model, assurance reviewed, material contract clauses, proof-of-concept results, accepted thresholds, unresolved findings and named risk owners.

Attach the key evidence instead of summarising it. Include the architecture, responsibility matrix, access demonstration, release and rollback result, restore result, sample explanation packet, assurance scope and exit test. Give each artefact an owner and version so a later reviewer can tell which evidence supported the decision.

Set reassessment triggers at approval time. Examples include a material architecture change, a new subprocessor, a different data region, new support access, a major matching-rule change, an assurance exception, repeated service failure or an acquisition. The bank should not have to invent its response after one of those events occurs.

The procurement answer is therefore conditional. A bank can choose an entity resolution deployment in its own cloud account when the architecture, operating model, contract and tested evidence meet its requirements, and specifically when the bank can show who holds the encryption keys, who owns the audit logs, and that a rehearsed exit produces its data, entities and configuration intact. Account ownership is useful evidence, but it is only one line in the control case.

Own-account deployment is not the right starting point for every bank. A bank without a dedicated cloud platform or security team able to own that responsibility matrix, or with a sourcing policy that requires a fully third-party-operated service instead of infrastructure it runs itself, should not choose it. Our Managed Cloud on AWS deployment is the better starting point there: we operate the infrastructure end to end, so the bank evaluates a contracted service and its assurance report instead of building and staffing its own key-management and logging programme.

Evaluate the control model with your own requirements

Book a Demo to review the deployment, key ownership and evidence boundary with our team, or Try Tilores Studio (Free) to test matching locally before a production decision.

Frequently asked questions

Is deployment in the bank’s AWS account enough for approval?

No. It gives the bank a strong infrastructure boundary, but approval should also confirm who holds the encryption keys, who owns the audit logs, and what the bank can prove about access, responsibilities, data flows, matching governance, monitoring, resilience, contractual rights and exit evidence.

What access should a supplier receive in the bank’s account?

Only the access justified by the agreed operating model. Define each role, approver, permitted action, duration, logging requirement and emergency path. Test denial by default and an approved support session before production.

Must a proof of concept use production personal data?

No. Begin with the minimum data needed to test the declared risks. Synthetic, masked or carefully selected records may be appropriate, but the bank must document what the test can and cannot prove about real data quality and matching behaviour.

How should a bank verify entity resolution quality?

Use labelled match and non-match examples that represent the bank’s difficult records. Measure precision and recall, inspect evidence for individual decisions, define review thresholds and replay the set whenever transformations, rules or software change.

Does a SOC 2 Type I report replace the bank’s due diligence?

No. Review its scope, date, exceptions and relevant controls, then combine it with architecture, contract, technical testing and the bank’s own control assessment.

Sources

1. Deployment Options: Run Tilores Where Your Data Is, Tilores.
2. Data Privacy and Security, Tilores.
3. Infrastructure-Agnostic Entity Resolution: Running Tilores on AWS, Another Cloud, or Your Own Hardware, Tilores.
4. Entity Resolution Proof of Concept: 7 PoC Inputs a Bank Needs in 2026, Tilores.
5. Shared Responsibility Model, Amazon Web Services.
6. AWS KMS keys (customer managed, AWS managed and AWS owned keys), Amazon Web Services.
7. CloudTrail concepts, Amazon Web Services.
8. DORA Q&A on ICT third-party arrangements, EIOPA.
9. Guidelines on Outsourcing Arrangements, European Banking Authority.
10. Controller or processor guidance, European Data Protection Board.
11. Documentation, OpenSanctions.
12. DORA Article 2 scope Q&A, European Insurance and Occupational Pensions Authority.
13. Guidelines 3/2018 on the territorial scope of the GDPR, European Data Protection Board.