They should consider governance, access scope, data quality, and the legal basis for reuse. A central repository can reduce friction and improve matching, but only if its identifiers are trustworthy and access is tightly governed. Organisations should also decide whether the repository supports only payments, or whether it can safely serve broader identity verification use cases.
Why a Central Addressing Repository Changes eKYC and Payments Design
A central addressing repository sits at the point where identity matching, payment routing, and customer onboarding begin to overlap. That makes it more than a convenience layer: it becomes a trust anchor for whether an address, identifier, or mapping can be reused safely across contexts. If the repository is weakly governed, teams can inherit stale, duplicate, or unauthorised records into workflows that assume the data is current and authoritative.
For organisations, the key question is not simply whether centralisation is efficient, but whether the repository is being asked to do more than its controls can justify. Reuse across eKYC and payments can improve consistency, but it also raises the bar for provenance, access restriction, retention, and legal basis. When the same repository supports multiple business functions, the blast radius of a bad record or an excessive access grant expands quickly. The practical issue is often less about the repository itself than about the confidence users place in it as a shared source of truth. In practice, many organisations discover governance gaps only after a disputed match, failed payment, or downstream account review exposes that the repository was treated as authoritative without being operated that way.
Where the repository supports regulatory workflows, organisations should also check whether reuse is consistent with the purpose for which the data was collected. The EU’s eIDAS 2.0 people should review the framework text carefully because identity reuse and interoperability are not the same as unrestricted reuse, and the governance burden rises as the scope broadens.
How Central Repositories Affect Matching, Reuse, and Control Boundaries
In practice, a central addressing repository works only when its lifecycle is treated as an active control, not a passive database. The repository needs clear ownership, defined update paths, and validation rules that reflect the specific use case. For eKYC, that means the data must support evidence of identity confidence, not just search convenience. For payments, it must also preserve integrity in routing or beneficiary selection so that a correct match does not become a misdirection risk.
The operational design choice is whether the repository serves one domain with one governance model, or multiple domains with different risk tolerances. That distinction matters because a field that is acceptable for payment messaging may be inadequate for identity verification, and a record that is sufficient for KYC screening may still be too weak to support payment operations. Centralisation helps most when the organisation has one source of truth for provenance, reconciliation, and exception handling. It helps least when teams treat the repository as a shortcut around local validation.
- Define which fields are authoritative, which are reference data, and which are only derived or temporary.
- Restrict write access so that only approved processes can create or change records.
- Check that duplicate detection, deactivation, and refresh rules are explicit rather than implied.
- Separate the permissions for lookup, enrichment, correction, and export.
For identity-led payments and onboarding, the most useful external comparator is often the legal and verification framework rather than a generic security control set. FATF guidance on AML and KYC expectations is relevant because it helps organisations test whether reuse improves assurance or simply increases trust in unverified data.
The guidance breaks down when organisations assume a central repository can resolve disagreements about identity quality, because process governance, not central storage, determines whether the record can be trusted.
Common Variations in eKYC, Payments, and Shared Data Models
Tighter centralisation often improves consistency, but it also increases coordination overhead, so organisations must balance operational simplicity against slower correction and stronger blast-radius management.
One common variation is a repository built primarily for payment addressing that is later reused for eKYC. That can work, but only if the original data model can support verification evidence, not just delivery or lookup. Another variation is the reverse: an identity repository is repurposed for payments, where timeliness and precision matter more than long-form identity detail. The two uses are related, but they are not interchangeable, and guidance across the industry is still not fully settled on how broad the reuse boundary should be. The safer position is to treat cross-use as an explicit governance decision, not an assumed benefit.
Another edge case is delegated data stewardship. If a business line can update the repository but does not own verification quality, the organisation may end up with strong operational convenience and weak assurance. That is especially important where third parties contribute data, because the repository may reflect upstream errors faster than it reflects correction. A useful benchmark is whether the organisation can explain who may change the record, who may rely on it, and what evidence exists when the record is disputed. The NIST security control catalogue at NIST SP 800-53 Rev 5 Security and Privacy Controls is helpful here because access, accountability, and data integrity are separate design concerns rather than one combined problem.
Where the repository is used across jurisdictions, the organisation should also check whether local legal basis, retention, and sharing rules differ by use case. The repository may be technically central, yet operationally fragmented once regulatory obligations are applied.
Risk and Threat Considerations
Central addressing repositories concentrate trust, so a single quality failure can propagate into both identity assurance and payment execution. The main risks are stale or incorrect records, overbroad reuse, unauthorised access, and mismatched purpose limitation between eKYC and payments.
Failure mechanism: Weak provenance, poor update control, or excessive access allows incorrect identifiers to be accepted as authoritative. That can lead to misidentification, false matches, failed onboarding, misrouted payments, or unauthorised data reuse across functions.
Impact: The organisation can lose confidence in the repository as a source of truth, expose regulated personal data to wider audiences than intended, and create operational disputes that are difficult to unwind once downstream systems have consumed the bad record.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-63 and CIS Controls v8 set the technical controls, while EU AI Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorizations are Managed | Central repository access scope must be tightly governed. |
| ID.AM-2 — Assets are Inventoried | A shared repository needs clear inventory and ownership of records. | |
| ID.GV-1 — Organizational Cybersecurity Policy Is Established and Communicated | Cross-use of eKYC and payments depends on explicit governance rules. | |
| Recommendation — Limit repository access to approved roles and revoke unnecessary permissions promptly. Maintain an authoritative inventory of repository data sets and accountable owners. Define policy for when identity data may be reused across payment and verification workflows. | ||
| NIST SP 800-63 | IAL2 — Identity Assurance Level 2 | eKYC reuse depends on the assurance level behind the identity data. |
| Recommendation — Match repository use to the assurance level of the collected identity evidence. | ||
| CIS Controls v8 | 5 — Account Management | Central records and access need controlled creation, change, and deletion paths. |
| Recommendation — Restrict record creation and modification to approved account and workflow owners. | ||
| EU AI Act | GOVERNANCE — AI Governance | Only relevant if automated matching or decisioning materially drives eKYC use. |
| Recommendation — Govern any automated identity matching used against the repository before production use. | ||
Practitioner Guidance
What to prioritise: Treat governance first, not the repository technology. The most important design decision is whether the same record can legitimately support both verification and payment use, or whether separate trust rules are needed.
What to verify: Confirm who can create, edit, approve, and consume each field; whether changes are auditable; and whether correction or revocation reaches every dependent workflow. If any of those steps are informal, the repository is not yet trustworthy enough for broad reuse.
Decision rule: If the repository cannot prove data provenance and purpose-specific access, limit it to the narrowest approved use case until those controls exist. Broad reuse should be earned, not assumed.
Practitioner takeaway: A central repository is valuable when it strengthens trust decisions; once it starts acting like a shortcut for weak upstream verification, it becomes a scaling mechanism for error.
Related resources from NHI Mgmt Group
- What should organisations consider before using public LLMs for security operations work?
- How can organisations reduce false positives when using anomaly detection for repository security?
- When should organisations avoid using AI for access review decisions?
- How should organisations decide whether to keep using traditional MFA?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
