Table of Contents
Clearing a KYC alert backlog takes four moves in order: stop the inflow, size and segment what is already open, work the queue by risk rather than by age, and fix whatever created the pile. Bulk closing is not one of the moves. An undocumented mass closure is treated more harshly than the backlog it was meant to solve.
Backlogs build quietly. A list publisher restructures its data, an acquisition lands a customer book with thin records, and suddenly the queue is three months deep.
What follows is a working method for clearing one, with the controls that keep the clear-down defensible. It applies whether your alerts come from customer screening, periodic review, or ongoing denied party screening across suppliers and counterparties.
Work out which backlog you actually have
The word backlog covers several different problems, and the fix differs for each. Separate them before you plan anything.
- Screening alert backlog. Name matches against sanctions, PEP or denied party lists sitting undispositioned. These carry the sharpest legal edge, because a real hit is a prohibition, not a risk factor.
- Onboarding backlog. Applications stuck in review. The cost here is commercial as well as regulatory, since customers walk.
- Periodic review or remediation backlog. Existing customers whose files are overdue for refresh, or whose records fail current standards. Large, slow, and usually driven by document collection rather than analysis.
- Transaction monitoring backlog. Behavioural alerts. Different skill set, different evidence, usually a separate team.
Most firms have more than one, and they interact. A screening backlog inside an onboarding queue delays revenue. A remediation backlog generates fresh screening alerts every time a record is updated. Plan them as one programme, run them as separate queues.
Stop the inflow before you start clearing
Teams skip this and then wonder why the queue never shrinks. If daily inflow exceeds daily capacity, no amount of overtime closes the gap. Work on the tap first.
Kill the duplicates
Check how many open alerts are repeat hits on pairs already cleared. In poorly configured systems this can be most of the queue. Proper suppression, tied to a specific customer record and a specific list record, removes them without any risk decision being made.
Find the flood event
Plot open alerts by creation date. Backlogs rarely accumulate evenly. Find the spike, then find what happened that day. A list republish, a bulk data migration, a threshold change pushed without testing. Fix the cause and a large block of the queue often turns out to be one repeated artefact.
Review discretionary list scope
Mandatory lists stay whatever the volume. Discretionary sources are a different question. If an adverse media source has produced nothing actionable in a year, take that evidence to your risk committee and ask to retire it. Do this through governance with a written decision, never by an analyst switching something off.
Fix the noisiest matching rule
One or two rules usually generate a disproportionate share of alerts. Phonetic matching on short corporate names is a common culprit. Any tuning change needs below-the-line testing before it goes live, and the results go in the file.
Size the queue honestly
You need six numbers before you can plan. Get them from the case management system, not from memory.
- Total open alerts, split by alert type.
- Age profile in buckets, for example under 7 days, 8 to 30, 31 to 90, over 90.
- Open alerts touching an active customer or a pending transaction.
- Average analyst throughput per day, measured from the last full month, by alert type.
- Daily inflow, averaged over the same period.
- Any alert with a hard regulatory or contractual deadline attached.
Then do the arithmetic. Divide the open volume by daily net capacity, meaning throughput minus inflow. If net capacity is zero or negative, the backlog is not clearable by effort and you need a structural change: suppression, tuning, scope reduction or surge staffing. Say so in writing rather than promising a date you cannot hit.
Order the queue by risk, never by date
First in first out feels fair and is the wrong rule. The oldest alert is often the least consequential, because a genuinely dangerous hit tends to sit on an active relationship that someone has already noticed.
Rank on exposure. A potential sanctions match on a live payment or a shipment about to move outranks everything. Below that, rank by list severity, customer risk rating, relationship status and value at risk. Write the ranking into a triage rule and apply it automatically, so nobody cherry-picks the easy cases.
| Alert type | Priority | Who reviews | Quality sample |
|---|---|---|---|
| Sanctions or denied party hit on a pending payment or shipment | Immediate, blocking | Senior analyst plus a second reviewer | Every case |
| Sanctions hit on an active customer, no live transaction | Same day | Senior analyst plus a second reviewer | Every case |
| Sanctions hit on a dormant or closed account | High | Analyst | Heavy sampling |
| PEP hit on a high-risk customer | Medium high | Analyst, escalate if confirmed | Moderate sampling |
| PEP hit on a low-risk customer | Medium | Analyst | Light sampling |
| Adverse media only, no list match | Lowest | Analyst | Light sampling |
Set the actual percentages to suit your size and your regulator’s expectations, then hold them constant through the clear-down so the numbers stay comparable week to week.
Build surge capacity that will survive review
Extra hands help only if they produce dispositions that stand up.
Train on your own closed cases, not on generic material. Pull thirty real alerts, half true and half false, strip the outcomes, and have every new reviewer work them before touching live cases. Compare their calls against the originals. Anyone who clears a true match in that set does not go on the queue yet. Broader compliance training matters, but case-based practice is what transfers here.
Keep relationship managers out of disposition. They can supply documents and context. They should not close an alert on their own client. The conflict is obvious to an examiner even when the decision was correct.
Require two people on every sanctions disposition, including the negatives. This costs time and it is the single control that most reliably prevents a real hit being cleared under pressure. Our walkthrough of how to process denied party screenings sets out the step sequence a reviewer should follow each time.
Run the clear-down in waves
A single undifferentiated push loses momentum and produces no useful data. Break the backlog into waves of fixed size and scope, each run as a small project.
Each wave takes one alert population, for example all sanctions alerts over 30 days on active customers. Give it a named owner, a start and end date, a target volume, and a quality gate at the end. Publish a daily burn-down: opened, closed, escalated, still open. If a wave misses its rate for two consecutive days, review the cause before adding people, because the usual cause is missing data rather than missing hours.
Define done precisely. An alert is closed when a disposition, a reason code, the evidence relied on and the list version screened are all recorded. Anything less is an open alert wearing a closed label.
Where a case stalls because the customer has not sent a document, move it to a separate pending queue with its own chase cycle. Do not let document chasing block analytical throughput, and do not close the case as resolved because the customer went quiet.
Sample for quality while you clear, not afterwards
Speed and accuracy move in opposite directions under pressure. Quality assurance run at the end tells you about damage you can no longer prevent.
Sample daily from each wave, using an independent reviewer who did not work the case. Classify every error rather than just counting it. A useful taxonomy separates wrong outcome, right outcome with missing evidence, wrong reason code, and missing second review. Those four failures have four different fixes.
Agree a stop rule in advance. If the wrong-outcome rate in a wave exceeds an agreed level, that wave pauses, the closed population is re-reviewed, and you find out why before restarting. Put the rule in the programme plan and get it approved, so that pausing is a planned control rather than an admission of failure.
Keep the sampling evidence. The quality record is what demonstrates the clear-down was controlled, and a proper audit trail across the whole exercise is what a supervisor will ask to see first.
Practices that turn a backlog into an enforcement problem
- Bulk closing alerts by name pattern, by age, or because a wave ran out of time.
- Raising the match threshold mid-clear-down so open alerts disappear from the queue.
- Closing a sanctions alert with a reason code and no evidence of how the identity was distinguished.
- Letting a single analyst both review and approve a sanctions negative.
- Deleting or reassigning alerts during a system migration without a reconciliation.
- Reporting queue size to the board without the age profile, which hides the oldest and most serious cases.
Auto-closing is not automatically forbidden, but it needs narrow, tested and documented rules, approved through governance, with sampling of what the rules closed. Blanket auto-closure with no rule set is indefensible. The judgement needed on individual cases is set out in our guide to resolving a false positive, and that judgement does not disappear because the queue is long.
Report it up, and consider telling your supervisor
A backlog you have identified, sized, planned and are reporting on is a managed issue. The same backlog discovered by an examiner is a control failure.
Log it formally as an issue with an owner and a target date. Report open volume, age profile, oldest item, weekly burn-down and quality results to the compliance committee on a fixed cycle. Where a backlog means screening obligations have not been met within required timeframes, take legal advice on whether disclosure to your regulator is required or advisable. Firms that self-identify and arrive with a plan generally have a better conversation than firms that are found out.
Retention rules apply to everything the clear-down produces. Dispositions, evidence, sampling results and the list versions screened all need keeping, and record keeping for denied party screening sets out what to hold and for how long.
Stop the next one forming
Clearing the queue is the short job. Keeping it clear is the real one.
Build a capacity model that states plainly how many alerts a day the team can absorb, and monitor inflow against it weekly. Set a trigger level at which extra resource is requested automatically, before the queue ages. Publish a list change calendar so that a known republish does not arrive as a surprise, and screen incrementally against list deltas where your system supports it, rather than re-screening the whole book each cycle.
Match screening frequency to risk instead of running everything on the same cycle, which is covered in more detail in our note on how often to screen suppliers and customers. For smaller teams without a case management platform, being able to run a denied party screening check on demand at the point of a new order keeps the queue from forming in the first place, and Globalior’s free screening tool covers the main public lists.
Key takeaways
- Reduce inflow before adding capacity, since a backlog with negative net capacity cannot be cleared by working harder.
- Duplicate alerts on pairs already cleared are often a large share of an open queue, and suppression removes them without any new risk decision.
- Order the queue by exposure, putting potential sanctions matches on live payments and shipments ahead of everything else.
- An alert is only closed when the disposition, reason code, supporting evidence and list version screened are all recorded.
- Sample for quality daily during the clear-down, classify errors by type, and agree a stop rule before you start.
- Two reviewers on every sanctions disposition, including negatives, is the control that most reliably prevents a true match being cleared under time pressure.
- A backlog that is logged, sized and reported is a managed issue, while the same backlog found by an examiner is a control failure.
Frequently asked questions
How long is too long for a KYC alert to stay open?
There is no single published number, because it depends on the alert type and your own policy. Set internal turnaround targets by type, with sanctions alerts on live activity measured in hours rather than days. What supervisors look at is whether you set a target, monitored against it, and escalated when you missed. An open target with no measurement is the weak position.
Can we bulk close obvious false positives?
Only under written rules that have been tested and approved, and only with sampling of the closed population. A rule such as suppressing an exact repeat of a pair already cleared against an unchanged list record is defensible. Closing everything over 90 days because it is old is not. The distinction is whether the rule encodes a reason, or just a shortcut.
Should we hire temporary analysts or buy technology?
Usually both, in sequence. Suppression and tuning reduce the volume, which shrinks how many temporary staff you need and for how long. Buying people first means paying to review alerts that better configuration would have removed. Neither works without quality controls, since volume cleared at low accuracy creates a second problem.
Do we have to tell the regulator about a backlog?
It depends on your jurisdiction, your licence conditions and whether the backlog means a legal obligation has been missed. Take advice rather than deciding informally. Many supervisors impose a general duty to notify material control weaknesses, and a screening queue that has prevented timely identification of a listed party can meet that bar.
What if the customer will not send the documents we need?
Move the case to a pending queue with a defined chase schedule and a decision point at the end. Non-response is itself information. Your policy should say what happens when the chase cycle ends, whether that is restricting the relationship, exiting it, or escalating. Silence from the customer is not a reason to close the alert as resolved.
How do we stop the backlog coming back after the clear-down?
Fix whatever caused it and keep measuring. That means tuning the noisiest rules with tested evidence, maintaining suppression, watching inflow against a stated capacity figure, and triggering extra resource automatically at a set threshold. Programmes that skip the root cause work clear the queue once and rebuild it within a year.
If you need a second pair of eyes on a clear-down plan or on the controls around it, speak to the Globalior team.