Evaluating Breach Detection Systems for Client Fund Compliance

Why Breach Detection Is a Distinct Capability

Breach detection is not a feature of reconciliation, it is a separate, complementary capability. Reconciliation answers the question: do the balances match? Breach detection answers a different question: are client funds adequately protected right now? A reconciliation can complete successfully, balances match across all three sources, while a breach condition exists because the total safeguarded balance is insufficient relative to client liabilities.

For compliance leaders evaluating breach detection systems, this distinction is important. A vendor that positions breach detection as a by-product of reconciliation is likely underestimating the complexity of the requirement. Effective breach detection requires its own data model, its own threshold logic, its own escalation workflows, and its own evidence trail.

Coverage Ratio Monitoring

The foundation of breach detection is continuous coverage ratio monitoring. The system must calculate, in near real-time, the ratio between safeguarded assets (what you hold in designated accounts) and client liabilities (what you owe to clients). Any ratio below 100% is a potential breach condition.

Evaluate how the system sources its data: does it rely solely on reconciliation outputs (which may be up to 24 hours old), or does it incorporate real-time data feeds from bank accounts, payment processors, and internal ledgers? The freshness of the data directly determines the speed of detection.

Look also at how the system handles multi-currency positions, in-transit funds, and settlement timing. A naive implementation that does not account for these factors will generate excessive false positives, undermining confidence in the alerting system and creating alert fatigue.

Escalation Logic and Notification Workflows

When a potential breach is detected, the system's escalation logic determines what happens next. Look for systems that support tiered escalation: an early warning when coverage ratios approach the threshold (allowing preventive action), a confirmed alert when the threshold is breached, and automatic escalation if the breach is not resolved within a defined period.

The notification workflow should be configurable: different frameworks require different notification recipients and timelines. Under PS25, the FCA expects notification within specific timeframes depending on the severity of the shortfall. Under CASS 7, the firm's CASS oversight function must be informed immediately. The system should support these framework-specific workflows without manual intervention.

Ask vendors whether the escalation logic is rules-based and configurable, or hardcoded. Your notification requirements will change as frameworks evolve, PS25 is still being refined, MiCA's Level 2 standards are being finalised, and your breach detection system must adapt without a software update cycle.

Evidence Trail for Breach Events

Every breach event must produce a complete, immutable evidence trail: when the breach was detected, what triggered it, who was notified, when they were notified, what actions were taken, and when the breach was resolved. This evidence is not optional, it is what regulators will request during a supervisory review or enforcement investigation.

Evaluate the system's evidence output carefully. Can it produce a chronological timeline of the entire breach event, from detection through resolution, in a format that can be provided to regulators? Are the timestamps cryptographically verifiable? Can the evidence be exported as a self-contained pack, or does it require access to the system to review?

The best breach detection systems treat evidence generation as a first-class function, not an afterthought. Every alert, acknowledgement, escalation, and resolution is logged automatically with full user attribution and timestamp integrity.

How Safeheld Addresses These Requirements

Safeheld's breach detection capability is purpose-built as a distinct layer, separate from but integrated with the reconciliation engine. Coverage ratios are calculated continuously from real-time data feeds, not derived from periodic reconciliation outputs.

The escalation workflow supports NT-1 through NT-4 notification stages with configurable recipients, timelines, and escalation rules for each framework. Every event in the breach lifecycle, detection, notification, acknowledgement, investigation, resolution, is recorded immutably with user attribution and SHA-256 timestamp verification.

The result is a breach detection system that meets the specific requirements of PS25, CASS 7, MiCA, and PSD2, while producing the evidence trail that regulators and auditors expect.