CASS Reconciliation Failures Don't Start in the Engine

How data architecture determines whether your CASS 7 programme actually works

There is a pattern that repeats itself across almost every CASS reconciliation programme we see. The operations team understands the process. The reconciliation platform is running. The breaks are being worked. And yet the match rate is poor, the exception queues keep growing, and the audit trail isn't clean enough to withstand FCA scrutiny.

The cause is almost never the reconciliation engine. It is what happens upstream of it.

CASS 7 reconciliation fails at the architecture stage — before a single transaction enters the matching queue. Proprietary accounts included in the CASS population generate false breaks. MT940 feeds load as flat files with no account-level filtering. Match rules are configured as a single type across account series with fundamentally different data topologies. Active account reference data goes stale between cycles. Break categories are undefined, so every exception lands in one undifferentiated queue for someone to sort manually.

These are not configuration problems. They are design problems. And they have design solutions.

This document sets out the data architecture and automated reconciliation framework we built for a Tier 1 broker-dealer operating across three custodian relationships, six currencies, and three distinct account series — all within a FIS IntelliMatch environment. It covers source file design, proprietary account filtering, two-tier matching logic, break code taxonomy, and the balance proof cycle. It is presented as a reference framework applicable across all automated reconciliation platforms.

With CASS 15 bringing payment institutions and e-money firms under an equivalent regime from 7 May 2026, the architecture described here is no longer the preserve of large broker-dealers. It is the operational baseline the FCA will expect.

ReconIQ_CASS 7_Architecture_Case_Study.pdf

Download PDF • 299KB