None of those fifteen requests are unreasonable on their own. Each correspondent is simply doing its job: confirming ownership, verifying licensing, understanding expected activity. The problem isn't the diligence — it's that the same underlying facts about the same client bank get re-collected, re-formatted, and re-verified independently, fifteen separate times, with fifteen separate chances for the answer to drift out of sync.
Where the duplication actually costs money
The visible cost is staff time — compliance teams on both sides re-keying answers into different templates instead of reviewing substance. The less visible cost is inconsistency: a client bank that updates its expected transaction volume for one correspondent has no structural reason to update the other fourteen files at the same time, so the same institution can appear differently risk-rated across its own correspondent network, simply because the paperwork drifted apart rather than the underlying business.
That drift matters at exactly the moment it's least convenient — during an audit, a regulatory exam, or when a new correspondent is doing due diligence on the client bank and finds answers that don't quite match what's on file elsewhere.
What a shared repository changes — and what it doesn't
A shared repository doesn't mean one correspondent sees another correspondent's risk assessment, or that ownership of the relationship shifts to a third party. It means the client bank maintains one current, authoritative record — built around a common questionnaire structure — that each correspondent draws from instead of requesting its own copy. Each bank still applies its own risk scoring and makes its own decisions; what changes is that everyone is working from the same underlying facts rather than fifteen independently maintained versions of them.
This is the same principle behind the shared questionnaire structure described in our piece on standardising KYC exchange across correspondent networks — a single data structure that every counterparty fills in the same way, rather than a template invented fresh for each relationship.
Where the savings show up in practice
- Onboarding a new correspondent takes days rather than the weeks needed to rebuild a KYC file from scratch
- Client banks update one record instead of chasing down every counterparty that holds a stale copy
- Renewal cycles pull from a document set that's already current, rather than restarting the collection process each time
- Discrepancies between correspondents surface immediately, instead of during an exam
Consolidation still needs monitoring built in
A shared file that's accurate on day one and stale by month six hasn't solved the underlying problem — it's just moved it. Pairing a shared repository with event-based monitoring, rather than relying on the next scheduled renewal, is what keeps the consolidated record trustworthy. We cover how that works in our article on Trigger Review Events.
Who's accountable when the record is shared
Consolidation raises an obvious question: if fifteen banks are drawing from one file, who's responsible for what's in it, and who can prove what was seen and when? That's a data-ownership question as much as a technical one, and it's worth answering before a shared repository is adopted rather than after. We look at how document ownership and audit trails should work in a shared exchange in our companion piece on KYC data ownership and audit trails.
The real argument for consolidation
Reducing duplicate requests isn't primarily about saving compliance teams from repetitive paperwork, though that's a real benefit. It's about removing the structural reason a single client bank's risk profile can look different depending on which correspondent is looking at it. One current record, visible on the same terms to every correspondent that relies on it, closes that gap directly.