Why refresh cycles are a nightmare for multi-counterparty companies
The hard part of KYB is not the first onboarding. It is the second, third, and tenth cycle across ten-plus counterparties, each with its own form, its own calendar, and its own document expectations. By year three a multi-bank fintech is handling fifty to a hundred refresh events annually.
When refresh is reactive — counterparty emails, team scrambles to fill in the form — the pattern is a continuous fire drill. A functional operator converts refresh from reactive to scheduled.
Refresh triggers
Time-based
- Annual anniversary of onboarding
- Biannual for low-risk relationships
- Semi-annual for high-risk / cross-border
- Document expiry (passport, good standing certificate)
Event-based
- UBO change (new equity holder, buyout, death)
- Director or officer change
- Address change (registered office, UBO residence)
- License status change (new, renewal, revocation)
- Company name or structure change
- Material change to compliance program
Refresh by counterparty type
| Counterparty | Typical cadence | What they ask for | Gotchas |
|---|---|---|---|
| Correspondent banks | Annual | COGS, UBO attestation, OFAC confirm, BSA/AML program summary, financials | Date-sensitive COGS (issued within 30–90 days) |
| Sponsor banks (US) | Annual + event | Full KYB packet + ongoing transaction attestations | Will freeze accounts if late |
| Payment processors | 12–24 months | Entity structure, UBO, compliance policies, chargeback ratios | Tied to merchant risk reviews |
| Exchanges and VASPs | Annual | Full KYB + jurisdiction-specific regulatory disclosures | Heightened scrutiny on UBO tracing |
| Card networks | Annual | BIN sponsor KYB, compliance program, AML attestations | Piggybacks on sponsor-bank packet |
| Marketplaces (for sellers) | 12–24 months | Entity verification, tax forms (W-8/W-9), UBO | Often portal-driven, token-authenticated |
| Custodians | Annual | Full KYB + investment manager disclosures | Often escalating questionnaire depth year over year |
Building a refresh calendar
A working refresh calendar has three layers:
- Counterparty registry. One record per counterparty with onboarding date, cadence, contact, portal link, required document set, and last submission metadata. Without this, refresh is guesswork.
- Document expiry register. Every document in the evidence vault has an issue date, expiry date, and a list of counterparties that received it. When a document nears expiry, every affected counterparty surfaces.
- Event router. UBO changes, director changes, and address changes ripple out to the counterparty registry and queue refresh submissions.
The output of the calendar is a rolling 90-day view of what is due, what is at risk, and what is overdue.
What to automate, what to keep manual
Automate
- Document expiry alerts (30/7/1 day)
- Counterparty-specific packet generation from canonical data
- Refresh-due-date calculation per counterparty
- Cross-reference between UBO change and affected counterparties
- Immutable snapshot of each submission
Keep manual
- Final review before submission (regulatory accuracy matters)
- Nuanced questionnaire answers that require compliance judgment
- Counterparty relationship management conversations
- Escalation handling for unusual refresh requests
How Archway helps
Archway was built around the refresh cycle. Every counterparty is a first-class entity in your workspace with its own requirements, cadence, and submission history. Document expiry surfaces every counterparty that needs a refreshed document. UBO changes surface every counterparty that needs a re-attestation. Every submission is snapshotted. See the product page for the full capability set.