© 2026 Macro Global. All Rights Reserved.
Traverse the article
FSCS exclusions such as LEGDOR – Legally Dormant, LEGDIS – Legal Dispute, BEN Beneficiary accounts with unverified beneficiaries, and HMTS – HMT Sanctions often sit quietly in an institution’s records, drawing little attention, until a crisis hits. In the intense scrutiny of an SCV review, these accounts can suddenly become compliance flashpoints. What once looked like a dormant balance under LEGDOR may now shift into a LEGDIS case, slowing down payouts, inviting regulator queries, and testing the institution’s readiness under pressure.
For the FSCS, the challenge is a delicate balancing act. On one side is the urgent need to protect eligible depositors and release funds quickly. On the other is the responsibility to prevent wrongful payouts. It’s within this tension that SCV exclusions become both a technical challenge and a strategic risk.
This blog explores where exclusions tend to surface in practice, and how institutions can make exclusion management a marker of resilience. By embedding clear governance, version-controlled rulebooks, and proactive testing of SCV files, firms can turn exclusions from late-stage surprises into early indicators of control strength.
Common Exclusion Categories in SCV Exclusion Files
Exclusions are the filters that keep the SCV clean, credible, and regulator-ready. By ring-fencing accounts until eligibility is proven, firms protect payout speed, minimise disputes, and build audit confidence.
In SCV reporting, these exclusions must be placed in the Exclusions View until their status is confirmed:
- LEGDOR: These accounts are classified as legally dormant and excluded from the main SCV until KYC activity, verification, or reactivation restores eligibility. They often involve inactive balances or uncontactable customers and require firms to demonstrate clear governance under COMP rules and PRA SS18/15.
- LEGDIS: Where ownership or entitlement is under legal dispute — such as probate cases, contested claims, or pending litigation — accounts must remain excluded. Institutions are expected to keep audit-ready logs until disputes are resolved, ensuring payouts are neither premature nor erroneous.
- HMTS: Accounts linked to depositors under financial sanctions are automatically excluded until sanctions are cleared.
- Institutions must reconcile SCV data against HMT sanctions lists in real-time, either daily or in response to specific events, as wrongful inclusion or payout can trigger regulatory breaches.
- BEN: Accounts held in trust, nominee, or fiduciary structures are excluded until all underlying beneficiaries are verified. Until full KYC and eligibility checks are complete, these remain outside the core SCV, as directed by COMP 11 and FSCS beneficiary guidance.
Why Potentially Eligible Exclusions in SCV Reporting are FSCS Red Flag
Borderline eligibility cases sit in the “grey zone” where accounts are neither clearly protected nor excluded. They usually stem from incomplete or outdated data, changes in account ownership, or system inconsistencies. While they can appear minor, supervisors view them as a material risk indicator.
Under the Deposit Guarantee Scheme Directive (DGSD), transposed into the PRA Rulebook, firms must be able to deliver a complete and accurate SCV and pay eligible depositors within seven business days. Borderline cases directly threaten that standard.
- Data Integrity Failures: Misaligned records between the core banking platform, SCV extract, and customer files undermine confidence in the entire submission. Even isolated mismatches are treated by the FSCS as potential systemic governance failures. Supervisors expect firms to monitor % mismatches per batch, trend them, and demonstrate remediation.
- Delayed Payouts: Eligibility disputes stop FSCS from executing its 7-day payout mandate. Firms with high volumes of borderline exclusions face challenge on mobilisation testing,
- with FCA/PRA review of clearance SLAs and backlog ageing. Any delay risks breaching depositor protection commitments and may trigger regulatory action.
- Customer Harm and Complaints: Deposit protection is a conduct safeguard. Wrongly excluded depositors face distress, financial hardship, and potential claims for compensation, which escalate reputational risk. Regulators expect MI on complaint volumes linked to exclusion disputes and evidence of rapid escalation to senior management.
- Regulatory Breach Exposure: Under-exclusion (paying ineligible depositors) is as serious as over-exclusion (wrongly denying eligible depositors), exposing firms to FSCS clawbacks, fines, and enforcement action. Supervisors assess both error types as equally serious.
- AML/Financial Crime Red Flags: Cases linked to incomplete KYC, unclear beneficial ownership, or suspicious transaction history overlap with AML obligations, creating dual regulatory risk (FSCS + FCA AML). FSCS expects these cases to be dual tracked: excluded in the SCV until resolved and escalated through the firm’s financial crime framework.
- Operational Workload and Cost: Each disputed case triggers manual review, cross-team coordination, and FSCS queries, straining resources during resolution when time is critical.
- Supervisory Confidence in the Firm: Persistent borderline cases suggest weak data governance, poor remediation planning, and ineffective oversight, all of which can lead to PRA/FCA often requiring management attestations, enhanced MI (management information), or heightened supervision until firms demonstrate sustained control.
Case Studies: Real-World SCV Exclusion File Triggers
When it comes to SCV exclusions, the line between a clear-cut case and a contentious dispute can be razor thin. Real-world failures have shown how seemingly dormant or borderline accounts can transform overnight into complex eligibility debates, often under the glare of regulatory scrutiny.
The following case studies illustrate how sudden account activity, ownership changes, incomplete KYC, or simple data mismatches can escalate from routine records into high-stakes payout decisions, underscoring why proactive monitoring and rigorous data governance are non-negotiable.
NFFSTP → LEGDIS: Disputed Identity
During resolution of a regional bank, several retail accounts flagged mismatches between passport details in the SCV file and the firm’s updated KYC records. FSCS could not confirm eligibility until the discrepancies were resolved. The accounts were initially placed in the SCV with NFFSTP status while the bank validated new ID documents. Only if there had been formal notice of a legal dispute or competing claims would they have been escalated to LEGDIS in the Exclusions View.
This case shows why KYC refresh cycles must be complete and IDs valid at the point of SCV submission. Otherwise, even genuine depositors face payout delays.
LEGDOR: Dormant Accounts
A retail bank in wind-down reported over 1,200 savings accounts with no depositor-initiated transactions for more than 15 years and no customer contact. These met the statutory definition of Legally Dormant under the Dormant Bank and Building Society Accounts Act 2008. The accounts were therefore placed in the Exclusions View with LEGDOR codes until claimants reactivated their entitlement.
The case reinforced the importance of systematically identifying legally dormant balances in SCV extracts, rather than leaving them ambiguous in a payout event.
Temporary High Balances (THB) – Not Excluded in SCV
A claimant deposited £750,000 after selling a property three months before the bank failed. The SCV showed the full balance. However, without supporting documentation, FSCS could not immediately confirm that the excess above £85,000 qualified as a Temporary High Balance (THB). The firm did not flag the account in the Exclusions View, as THBs are not coded in SCV or Exclusions files. Instead, FSCS assessed the THB eligibility post-failure, once the claimant provided the sale deed.
This case shows why firms need a process to capture and evidence potential THBs internally, with clear audit trails, even though they do not flag them in SCV submissions.
BEN vs. LEGDIS: Beneficial Ownership
An SME account appeared in the SCV under its original shareholder information, but Companies House had recorded a change of control two months earlier. FSCS queried eligibility because the SCV record was not aligned with the current corporate ownership. The firm was required to reconcile and update customer details. Since the account holder remained the company itself, this was not a BEN (beneficiary account) case. It was a data-integrity issue, and only if there had been a formal dispute over entitlement would it fall into LEGDIS.
This situation highlights why corporate ownership structures must be reconciled promptly against public registries and internal KYC records, otherwise payout decisions stall.
Case study | Correct classification | Key points | FSCS SCV Guide references |
| Disputed Identity (passport vs. updated ID mismatch) | NFFSTP (status code) until resolved. Escalate to LEGDIS only if there is a formal legal dispute or competing claim. | Pure data/KYC mismatch ≠ legal dispute. Must be fixed in SCV, not Exclusions View, unless dispute notice is served. | Q18–Q22 (status codes, pp. 42–44); Exclusions definitions (p. 58) |
| Dormant Accounts (15+ years no contact) | LEGDOR (Exclusions View) if meets statutory dormancy definition under Dormant Bank & Building Society Accounts Act 2008. | Internal “dormancy” ≠ “legally dormant.” Only 15-year statutory test qualifies. Must be separately tagged in SCV/Exclusions. | Dormant accounts definition (p. 58); Q42 (joint dormancy, pp. 61–62) |
| Temporary High Balances (THB) (property-sale £750k) | Not flagged in SCV or Exclusions View. THBs are assessed by FSCS post-failure. | Firms should keep internal evidence/audit trails but must not code THB as HMTS or Exclusion. | Temporary High Balances section (pp. 53–54) |
| Beneficial Ownership / Company control change (SME account with shareholder change) | Data integrity fix (update non-individual depositor details). Not BEN unless trustee/nominee account; not Exclusion unless competing claims (→ LEGDIS). | Company remains the legal account holder. Ownership disputes = LEGDIS; client/trust/nominee = BEN. | Non-individual details (pp. 19–21); BEN definition (pp. 59–60); Q40–Q45 (beneficiary FAQs, pp. 61–64) |
Compliance and Data Governance Implications for FSCS
Within FSCS reviews, exclusion decisions are best defended when supported by clear compliance frameworks and disciplined data governance. Transparency and well-documented decision-making are regarded as essential in reducing the risk of disputes and in demonstrating operational maturity.
When definitions, logic, and records are kept consistent across systems, ambiguity is minimised, both for regulators and for customers.
Best Practices to Strengthen FSCS SCV Reporting and Exclusion Governance
- Treat every exclusion as an audit trail in waiting: An exclusion is a regulatory decision that must stand up to inspection. Each record must capture the exclusion code (LEGDOR, LEGDIS, HMTS, BEN), evidence source, approver, timestamp, and SCV batch ID. Metadata should reference the relevant SCV Guide section and, where applicable, the corresponding COMP/PRA rulebook clause. The system must allow step-by-step replay of how eligibility was tested, decision criteria applied, and category assigned.
- Speak a single language of eligibility: Eligibility definitions must be consistent across SCV generators, core banking, CRM, and compliance rulebooks. LEGDOR cannot be misinterpreted as operationally inactive. HMTS (sanctions) screening results must cascade uniformly across systems. THBs are a separate protection class and are not flagged in SCV/Exclusions; firms must track THB claims internally. Schema mapping must ensure that exclusion codes LEGDOR, LEGDIS, HMTS, BEN are not redefined at the application or reporting layer.
- Turn exceptions into early-warning intelligence: Exception reporting must flag logical contradictions,
- for instance, where LEGDOR with active standing orders, or HMTS without expiry metadata. Reports must reconcile across account activity feeds, SCV category codes, and dispute registers. Thresholds should be calibrated to ensure SCV readiness within T+1, evidencing compliance with the 7-day payout requirement.
- Make data hygiene continuous: SCV accuracy depends on upstream hygiene. Reconciliations between AML/KYC, customer information files, and core ledgers must be embedded as daily or intraday jobs. Name, address, date of birth, and unique customer reference must cascade cleanly into the SCV. Remediation logs must flow into SCV refresh cycles without manual intervention.
- Practise for failure: Testing must assume the worst: disputed joint accounts, incomplete KYC, beneficiaries with missing National Insurance Numbers, or balances close to the £85k cap / potential Temporary High Balances. Dry runs should replicate end-to-end mobilisation with exclusion logic, approval routing, and customer notification, all within the 24-hour window. Test packs must be retained as audit artefacts.
- Align minds before aligning machines: Automation must only enforce a single, controlled interpretation of eligibility. Rulebooks must be version-controlled, baselined to the FSCS SCV Guide, and cross-referenced to COMP. Change control must require joint approval from Operations, IT, and Compliance before any production change. Divergent interpretations across systems create systemic risk.
- Demand transparency from algorithms: Algorithmic exclusions must map directly to LEGDOR, LEGDIS, HMTS, or BEN, with field-level lineage back to raw data attributes. Decision paths must be logged in as human readable plain text for one-pass supervisory review. Audit views must explain which fields triggered exclusion rather than hiding in compiled logic.
- Pressure-test blind spots: Exclusion frameworks must be tested with known weak spots: dormant accounts reactivated just before failure, unverified trust beneficiaries, opaque SME ownership structures, or incomplete KYC in joint accounts. These scenarios must be run in regression packs and signed off as part of SCV assurance.
- Build systems that remember everything: Exclusions must leave a permanent, immutable record: exclusion category, event timestamp, batch ID, data lineage, approving authority, and COMP reference. The system must allow regulators to replay the decision at both account and population level, reconstructing eligibility outcomes as if in real time.
- Stay ahead of the rulebook: Horizon scanning must be integrated into governance. Updates to COMP or SCV Guide must trigger controlled updates to business rules, exclusion logic, and thresholds. For example, revised HMTS caps must be recalibrated in the SCV generator and validated in payout simulation before effective date. Firms running on outdated logic fail regulatory readiness.
Turning FSCS SCV Reporting into Operational Excellence
Exclusion decisions in SCV are rarely straightforward, especially when dormant, borderline, or disputed accounts are involved. As FSCS scrutiny continues to sharpen, the institutions that succeed are those that view eligibility governance as a living process, not a static compliance tick-box. Revisiting exclusion criteria today is not just about avoiding regulatory penalties tomorrow; it is about safeguarding depositor trust and ensuring payout readiness under the most challenging scenarios.
Macro Global’s SCV Alliance and SCV Forza are built to address exactly these grey zones, delivering automated eligibility checks with explainable AI, near-real-time exception logging, and embedded audit trails designed in line with FSCS and PRA expectations. By combining regulatory precision with operational agility, these platforms help clients strengthen readiness and resilience.
Institutions that act now, refining rulesets, cleaning data, and deploying transparent SCV solutions, will enter any regulatory review not with anxiety, but with confidence. Partner with Macro Global today to turn exclusion governance from mere compliance into your mark of operational excellence.
Turn SCV Exclusion Complexity into FSCS Compliance Confidence
SCV Alliance
FSCS SCV Audit Platform
