Reconciliations Architecture

The break is rarely where you think it is

A daily reconciliation that generates 40 exceptions is not a reconciliation problem — it is a symptom of misaligned data at the point of origination, compounded by a matching process that was designed around the exception rather than designed to prevent it.

Organisations at this tier typically encounter one or more of the following patterns:

Phase 1 — Reconciliation diagnostic (weeks 1–4)

Fixed fee. We map your current reconciliation estate: data sources, matching logic, exception volumes by category, resolution workflows, and the downstream consumers of reconciliation output. We do not assume — we verify against your actual schema and live data flows.

The output is a written findings document that identifies the root causes of your highest-volume exception categories, the architectural changes that would address them, and a prioritised recommendation for what to fix first and why.

Phase 2 — Architecture redesign (scope defined post-diagnostic)

Based on diagnostic findings. This phase addresses the structural issues identified: data model corrections, matching rule redesign, snapshot and confirmation patterns where appropriate, and automation of exception routing for categories that can be resolved deterministically.

Where a platform migration is warranted — off an incumbent tool or onto a new one — this phase includes vendor evaluation, migration planning, and implementation governance. We do not have vendor partnerships that bias our recommendations.

Phase 3 — Operational handover

Every engagement concludes with documentation your team owns: architecture decisions recorded with rationale, runbooks for exception categories that require human review, and reporting logic that does not depend on who originally built it. We do not create dependency.

• All engagements led by the same people who scoped them
• No subcontracting of delivery without explicit client agreement
• Diagnostic findings are yours regardless of whether phase 2 proceeds
• Rate card and scope confirmed before any work commences

Bank and nostro reconciliation

Matching internal ledger positions against bank statements and custodian records. Particularly for organisations with multiple entities, multiple currencies, or treasury operations that have grown beyond their original architecture.

Customer data set reconciliation

Aligning customer records, balances, and transaction histories across core banking, CRM, and reporting systems. For institutions where the single customer view exists in aspiration but not in practice.

Money market and deal reconciliation

Term deposits, FX, and short-dated instruments where settlement confirmation and position matching require precision at the deal level. Organisations with treasury exposure where SWIFT exception handling is a relevant specialist depth.

Payment and settlement flow reconciliation

NPP, BECS, and card settlement matching. Particularly relevant for non-bank lenders and credit unions operating payment infrastructure without the internal engineering capacity to maintain it properly.

Regulatory and reporting reconciliation

Ensuring that what is reported to APRA, ASIC, or ATO reconciles to what is held in source systems. For organisations that have received findings, or that have the good sense to address this before they do.

The following represent the order of magnitude of outcomes we have designed for and delivered in comparable environments. They are not guarantees — they are directional benchmarks for what a structural fix to a reconciliation architecture can produce.

What does not change

We are not in the business of overstating outcomes. A reconciliation architecture redesign does not eliminate human judgement from complex exception categories. It eliminates the manual investigation of exceptions that should never have been exceptions in the first place — which, in most environments, is the majority of the daily workload.

The value is not in the technology. It is in the decision to design the system properly — and in having the experience to know what properly means in a regulated financial services environment.