KYC Remediation Planning Pack

Complete this before committing to a delivery plan. Scope estimated from a sample is the most common cause of remediation overrun.

• Population definition: which customer records are in scope, and the written rule that decides in and out.
• Source systems: which system holds the record of truth for each field, and what happens where sources disagree.
• Extract validation: has a full extract been validated, not just a sample? Extract defects are usually systematic.
• Data standard: the required field set by customer type and risk rating, signed off by the accountable owner.
• Gap profile: completeness measured across the whole population against that standard, by segment and vintage.
• Gap categories: which gaps can be closed from internal data, from registry or external sources, and only by the customer.
• Duplicates and related entities: how are they identified, merged or linked before work begins?
• Out-of-scope but affected: accounts closed, dormant or in exit, and the treatment agreed for each.
• Prioritisation rule: what determines sequence, typically risk rating, ageing and gap severity together.

Use these as the requirement headings when comparing options, whether or not Agora is one of them.

• Ingestion: structured upload, integration, or both; reconciliation against the source; versioned scope set.
• Gap identification: automated completeness assessment against a configurable, versioned data standard.
• Enrichment: registry retrieval of entity details, status, nature of business and ownership, with source and date recorded on every field.
• Ownership: recursive chain resolution to a configurable threshold, with unresolvable branches flagged rather than silently dropped.
• Screening: batch re-screening with firm-configured matching rules applied before alerts are raised.
• Risk assessment: configurable factors, weighting and thresholds, with methodology versioning.
• Workflow: routing by segment, risk and gap type; role-based queues; escalation; rework retaining the original submission.
• Outreach: structured requests, document return, chase tracking and non-response handling.
• Quality control: configurable sampling, structured defect taxonomy, recheck loops, separation of doer and checker.
• Evidence: exportable per-case pack covering what was checked, found, decided and by whom.
• Reporting: progress, exceptions, ageing, defect rates and outreach status from live data, drillable to the case.
• Exit: data portability and export format on termination, agreed before contract, not after.

Answer these before configuration. Workflow technology will faithfully enforce a badly designed process.

• Which roles exist, and which combinations of roles are forbidden on the same case?
• What are the permitted case states, and which transitions are prohibited?
• Which escalations are mandatory and which are discretionary?
• Where is accountable human judgement genuinely required, as opposed to habitually applied?
• What is the rule for accepting a file where a gap cannot be closed from any source?
• Who approves a departure from the standard, and how is the rationale captured?
• How are complex ownership structures routed, and to whom?
• What is the treatment of a customer who does not respond to outreach, including any customer impact?
• How are conduct and vulnerable customer considerations reflected in outreach design?
• What is the handover point between remediation and business as usual?

Agree these before go-live. Defect categories retrofitted later destroy the comparability of everything checked before them.

• Defect taxonomy: the defined categories, agreed with first and second line.
• Severity definitions, and what each severity triggers.
• Sampling model: rate by reviewer, case type, risk band or recent defect history.
• Accreditation: does demonstrated quality reduce sampling, and what reverses that?
• Separation: who may check whose work, enforced in configuration as well as in policy.
• Rework loop: does the record retain the original submission, the defect and the recheck outcome?
• Independent assurance: how second line sampling is held separately from first line quality control.
• Thresholds: the pass rate or defect level at which delivery pauses for root-cause work.
• Root cause: how defect trends feed policy, training or configuration change, and who owns that.

Agree the reporting set with the people accountable for the programme, not only with the project team.

• Progress against the versioned scope set, not against a moving denominator.
• Gap closure by category, showing where remaining effort actually sits.
• Exception volumes by type, and ageing within each queue.
• Automated resolution rate: records resolved without reaching a human queue.
• Screening alert volumes before and after rule calibration.
• Outreach issued, responded, chased and unresolved, with ageing.
• Quality pass rate, defect distribution by category and severity, and repeat defects.
• Rework volumes and time in rework.
• Forecast to completion, with the assumptions stated.
• Anything committed externally, reported in the terms of that commitment.

The test is whether someone who was not there can reconstruct the decision. Assemble this as the work runs, not afterwards.

• The data standard version applied to each record.
• Source and retrieval date for every enriched or refreshed field.
• Screening configuration and matching rules in force when the record was processed.
• Match disposition decisions, with reasoning and the person responsible.
• Ownership conclusion and the basis on which control was determined.
• Risk rating, the methodology version and the factor values behind it.
• Any override, with the reason, the approver and the supporting rationale.
• Quality check outcome, defects raised, corrections made and recheck result.
• Outreach correspondence and documents received.
• Final acceptance: who accepted the file, when and against which standard.
• Programme-level closure statement: scope, method, exceptions and residual items.

Decide the destination before completion, or the remediated population begins to age the day the programme closes.

• Where do remediated records land: existing periodic review, trigger-led review, or a combination?
• If trigger-led, what is the trigger taxonomy, and what does each trigger cause to happen?
• How is ongoing monitoring evidenced for a customer with no triggers in a period?
• Which scheduled review points are being retained, and what is the documented rationale?
• What is the expected steady-state trigger volume, and has it been modelled?
• Who owns the data standard once the programme ends, and how is change to it governed?
• How is the remediated evidence retained, and for how long, under your retention policy?
• What would tell you, twelve months on, that the population is staying current?