Setting up KYB refresh cycles that actually catch changes

In late 2024, an EU e-money institution failed a thematic review. The headline finding was not a missed sanctions hit or a poor onboarding decision. It was that 41% of its corporate customers had not been reviewed in more than three years, and the firm could not produce a documented refresh policy that explained why. The regulator's draft notice cited "systemic failure to operate ongoing customer due diligence on a risk-sensitive basis". The remediation programme cost the firm an estimated EUR 1.8M and burned 14 months of senior management attention.

The cause was not negligence. The cause was the absence of a refresh cycle that actually ran. The firm had a policy document. The policy said "customers will be reviewed periodically on a risk-sensitive basis." Nothing in the policy specified what "periodically" meant, what triggered a review, or how the firm would know when a review was overdue. So the reviews did not happen.

This is the most common failure pattern we see in KYB refresh programmes. The policy exists. The operational mechanism does not. This post is a practical setup guide for building the mechanism.

Why "annual for everyone" fails in two directions

The default refresh model that most firms adopt when they first take ongoing due diligence seriously is a flat annual cycle. Every corporate customer gets reviewed once a year. It feels safe because it is uniform, and uniformity is easy to defend.

It fails in two directions at once. For low-risk customers (regulated entities, public companies, stable family businesses with no material change in three years), annual reviews consume analyst capacity without producing any new information. For high-risk customers (complex structures, high-risk jurisdictions, recent change in control), annual reviews are not frequent enough. The high-risk customer who acquires a subsidiary in a sanctioned jurisdiction in February will not be reviewed until November.

The regulatory expectation, set out in FATF Recommendation 10, the EU AML Regulation, and the FCA Financial Crime Guide, is for ongoing due diligence proportionate to risk. AMLA's draft implementing technical standards push this further with explicit cadence guidance for higher-risk customers. The expectation is a risk-band cadence, not a uniform one. See our AMLA overview for the wider framework.

Step 1: define your risk-band cadence

The first deliverable is a cadence table. Three bands minimum. Most teams settle on four.

Two practical notes on the cadence design.

Tie the band to the risk score, not to the segment. A small business is not automatically lower risk than a large one. A small business operating through three offshore entities is higher risk than a 500-employee UK regulated firm. The band assignment is driven by the calculated risk score from your onboarding methodology, not by superficial characteristics.

The cadence is a maximum, not a minimum. A customer in the standard-low band reviewed every 24 months can be reviewed earlier if events demand it. The cadence sets the longest acceptable gap between reviews in the absence of triggers. Triggers can shorten the gap. Nothing should lengthen it.

Step 2: define your event-driven triggers

Cadence on its own is not sufficient. Most material changes happen between scheduled reviews. Event-driven triggers are what turn an annual review into ongoing monitoring.

The trigger list below is the baseline we recommend. Each trigger initiates a refresh out of cycle, with the scope adjusted to the nature of the event.

• Sanctions hit or change in sanctions status on the customer, a director, or a beneficial owner. Immediate full review.
• PEP status change in the ownership chain. Standard refresh within 30 days, with enhanced measures applied.
• Adverse media match above the relevance threshold. Targeted review focused on the issue, escalated to full refresh if material.
• Change in control detected through registry monitoring, share allotment or transfer filings, or company announcements. Full UBO and structure re-verification.
• Change of registered office, particularly to a higher-risk jurisdiction or to a known formation-agent address. Targeted review of jurisdiction risk.
• New subsidiary or new parent appearing in the corporate structure feed. Structure re-verification, with cascade screening on the new entity.
• Filing failure or company status change (overdue accounts, strike-off notice, insolvency event, dormant status). Operational review, often leading to relationship review.
• Transaction monitoring alert that the financial intelligence team escalates as a KYB concern (for example, transaction patterns inconsistent with declared business activity). Full review.
• Counterparty risk event: a significant counterparty of the customer is sanctioned, sanctioned, or subject to adverse media. Targeted review.
• Customer-initiated change: addition of new directors, new beneficial owners, new business lines, or new jurisdictions of operation declared by the customer. Targeted review of the change.

The point of explicit trigger definitions is that they remove the judgement call of "is this material enough to act on?" from the analyst in the moment. The trigger fires, the review starts. Judgement applies to the conclusion of the review, not to whether to start it.

Step 3: wire the cadence into your operational stack

A cadence policy is only worth the document it sits in if your operational system enforces it. The wiring has three components.

Next-review-date field on every customer record. Calculated from the last review completion date plus the band cadence, recalculated whenever the band changes. This field is the single source of truth for whether a customer is current.

Automated overdue detection. A daily job that produces three lists: customers due in the next 30 days (workload pipeline), customers overdue by less than 30 days (analyst attention), customers overdue by more than 30 days (escalation). These lists feed the work queue and the compliance dashboard.

Trigger ingestion. Each event-driven trigger is wired to a source: sanctions feed, adverse media feed, registry change feed, transaction monitoring alerts, internal escalations. When a trigger fires, the system creates a refresh work item with the trigger as context, sets the priority, and routes to the appropriate band's queue.

The point about wiring is that overdue should be impossible to ignore. It should appear on the MLRO's dashboard, on the head of compliance's weekly KPI report, and on the board pack. If overdue is invisible, overdue grows. This is the operational gap that the EMI in our opening example fell into.

Step 4: size your refresh capacity

Capacity planning is where most KYB refresh programmes quietly fail. The cadence policy is approved, the triggers are defined, and then nobody calculates whether the team has the hours to actually do the work.

The capacity model is straightforward. For each band, multiply the population by the annual review frequency to get annual reviews required. Multiply by the typical analyst hours per review (allowing for data gathering, change detection, individual rescreening, risk reassessment, and documentation). Sum across bands. Add a 20% to 30% allowance for event-driven reviews. Compare to available analyst hours per year.

(Note: the hour ranges above are typical of what we see across mid-market UK and EU firms. Your numbers will vary with data quality, automation level, and analyst seniority.)

For the worked example above, 4,500 to 7,300 hours translates to between 2.5 and 4 full-time analysts dedicated to refresh activity. If your actual capacity is below that range, you have three levers: shift bands to extend cadences where the risk allows, automate change detection so analysts only review actual changes, or hire. Hiding the shortfall is what produces 41% overdue rates.

Step 5: evidence completeness to a regulator

The final piece, and the one that separates a refresh programme that works from one that exists on paper, is the ability to produce evidence on demand.

The questions a regulator will ask are predictable.

• What is your documented refresh cadence by risk band? Where is the policy and when was it approved?
• What proportion of your corporate customers are within their refresh cadence? Show the breakdown by band.
• For a sample of 20 customers, produce the last refresh evidence: date completed, data sources used, changes detected, actions taken.
• What is your overdue position? How long are the overdue customers overdue for? What is the remediation plan?
• What triggers do you operate for event-driven reviews? Show three examples from the last quarter.

If you can produce all five answers within a working day, your programme is operating. If not, you have a gap, and the regulator will find it.

The systems requirement is a single source of truth for KYB refresh status, with a complete audit trail per customer (review dates, data sources, change detection output, risk reassessment, analyst decisions, documentation captured). The companion post on re-verifying business information without killing productivity covers the analyst-workflow side of this in more detail.

Where the orchestration layer earns its keep

Most of the operational pain in refresh comes from data fragmentation. Different jurisdictions have different registries. Different providers cover different entity types. UBO data for an offshore holding company comes from a different source than a UK PSC filing.

An orchestration layer (a single integration point that routes refresh queries to the appropriate provider for each entity and aggregates the results back into your record) is what makes risk-tiered refresh operationally feasible at scale. Without it, the cost of maintaining a dozen vendor connections in your KYB workflow consumes the savings you got from automating the cycle in the first place. See how Zenoo's KYB orchestration handles this, or the ongoing monitoring use case for the full operational pattern.

Key takeaways

• Annual refresh for everyone fails in two directions: too much work on low-risk customers, not frequent enough for high-risk ones. The regulatory expectation is risk-band cadence, not uniform cadence.
• Define three or four bands with explicit cadences (enhanced 6 to 12 months, standard high 12 months, standard low 24 months, simplified 36 to 72 months). Tie the band to the risk score, not to superficial segment characteristics.
• Wire event-driven triggers into the cadence: sanctions, PEPs, adverse media, change in control, registered office change, new subsidiary, filing failures, transaction monitoring alerts, counterparty risk events, customer-initiated changes.
• Operational wiring is the difference between a policy that works and one that does not: next-review-date field, automated overdue detection, trigger ingestion. Overdue should be impossible to ignore.
• Capacity planning makes or breaks the programme. If your modelled hours exceed analyst capacity, your only options are extending cadences within the risk envelope, automating change detection, or hiring. Hiding the shortfall produces 41% overdue rates and regulator notices.
• Evidence the programme through a single source of truth with complete per-customer audit trails. If you cannot produce refresh evidence for a 20-customer sample within a working day, the regulator will treat the policy as paper-only.