Chapter 2: The Universal Reconciliation Architecture

#

Part 2 of the Reconciliation Systems in BFSI series

Why does reconciliation exist?

This chapter should answer:

How does every reconciliation system work, regardless of business domain?

Notice what we are not doing.

We are not yet talking about banking reconciliation, insurance reconciliation, Geneva reconciliation, or payment reconciliation.

Instead, we are developing a universal architecture that will later apply to every one of those domains.

This chapter is probably the most important chapter in the entire book because once readers understand it, every reconciliation process becomes a variation of the same architecture.

Every Reconciliation System Follows the Same Fundamental Design

2.1 Introduction

#

In the previous chapter, we learned that a single Business Event creates multiple System Representations.

Because these representations are maintained independently, differences are inevitable.

This naturally leads to the next question.

How do organizations compare these independent representations and determine whether they agree?

The answer is surprisingly elegant.

Although reconciliation processes appear very different across banking, payments, insurance, lending, capital markets, and alternative investments, almost every reconciliation platform follows the same fundamental architecture.

Whether the reconciliation compares:

• Bank vs General Ledger
• ATM vs Core Banking
• Visa vs Merchant
• Custodian vs Portfolio Accounting
• Geneva vs Prime Broker
• Insurance Premium vs Bank Collection

the underlying architecture remains almost identical.

This chapter develops that universal architecture.

Once understood, every reconciliation process becomes a variation of the same design.

2.2 The Universal Reconciliation Problem

#

Every reconciliation system begins with a simple situation.

There are two or more independent systems.

Each contains information about the same business event.

The objective is to determine whether those systems agree.

The problem can be represented as follows.

                    Business Event
                          │
        ┌─────────────────┼─────────────────┐
        ▼                 ▼                 ▼
   System A          System B          System C
        │                 │                 │
        └─────────────────┼─────────────────┘
                          │
                Reconciliation System
                          │
                    Final Decision

Regardless of industry, this architecture never changes.

Only the systems involved are different.

2.3 The Seven Stages of Every Reconciliation System

#

Although implementations vary, every reconciliation platform performs seven logical stages.

Sources
   │
   ▼
Collect
   │
   ▼
Normalize
   │
   ▼
Match
   │
   ▼
Compare
   │
   ▼
Classify Breaks
   │
   ▼
Resolve
   │
   ▼
Audit & Report

Everything else is simply a variation of these seven stages.

Let’s examine each stage.

Stage 1 — Collect

#

The first responsibility is obtaining data.

Information may arrive from:

• Core Banking
• Trading Systems
• Custodian
• Prime Broker
• Payment Gateway
• SWIFT
• ERP
• General Ledger
• Insurance Systems
• Excel
• CSV
• APIs
• Databases

Each source is considered authoritative for its own data.

Example:

Core Banking
      │
      ▼
Daily Transactions.csv

General Ledger
      │
      ▼
Ledger Extract.csv

The reconciliation platform collects both.

At this stage, nothing has been compared.

Stage 2 — Normalize

#

Different systems rarely use identical formats.

For example:

Although they represent the same information, computers cannot compare them directly.

Normalization converts data into a common internal representation.

For example:

Date → YYYY-MM-DD

Currency → ISO Currency Code

Amounts → Decimal

Text → Standard Case

Identifiers → Standard Format

Without normalization, reconciliation would generate numerous false differences.

Stage 3 — Match

#

Once the data is standardized, the system determines which records correspond to the same business event.

This process is called Matching.

For example:

System A

Trade ID = 12345
Amount = 5000
Date = 10 May

↓

System B

Trade ID = 12345
Amount = 5000
Date = 10 May

These two records probably represent the same trade.

The matching engine establishes that relationship.

Notice an important distinction.

Matching answers:

Which records belong together?

It does not answer whether they are equal.

That comes next.

Stage 4 — Compare

#

Now that corresponding records have been identified, the reconciliation engine compares their values.

Typical comparisons include:

• Amount
• Quantity
• Currency
• Trade Date
• Settlement Date
• Interest
• Fees
• NAV
• Security Identifier

For example:

Result:

Matched.

Another example:

Difference detected.

Stage 5 — Classify Breaks

#

Finding differences is not enough.

The reconciliation platform must explain them.

Typical classifications include:

• Timing Difference
• Amount Difference
• Missing Transaction
• Duplicate Transaction
• Currency Difference
• Settlement Difference
• Reference Data Difference
• Corporate Action Difference

This classification helps operations teams prioritize work.

For example:

Difference = Timing

↓

Wait until tomorrow

Difference = Missing Trade

↓

Investigate immediately

Not every difference requires urgent action.

Stage 6 — Resolution

#

Once breaks are identified, operations teams investigate them.

Possible outcomes include:

• Book missing transaction
• Reverse duplicate entry
• Correct amount
• Wait for settlement
• Update reference data
• Contact broker
• Contact custodian
• Escalate to operations

The objective is to eliminate the break while preserving a complete audit trail.

Stage 7 — Audit and Reporting

#

Every reconciliation process must be auditable.

Organizations need answers to questions such as:

• When was the break detected?
• Who investigated it?
• What action was taken?
• When was it resolved?
• Was management notified?
• Was the regulator informed?

This information supports governance, compliance, and operational transparency.

2.4 The Universal Architecture

#

Combining all seven stages gives us the complete reconciliation architecture.

             Business Event
                    │
      ┌─────────────┼─────────────┐
      ▼             ▼             ▼
 Source A      Source B      Source C
      │             │             │
      └─────────────┼─────────────┘
                    ▼
             Data Collection
                    ▼
             Data Normalization
                    ▼
              Matching Engine
                    ▼
            Comparison Engine
                    ▼
          Break Classification
                    ▼
          Exception Resolution
                    ▼
          Audit & Reporting

This architecture is remarkably stable.

Whether implemented in a small bank or a global asset manager, the logical flow remains the same.

2.5 Domain Independence

#

One of the most important insights in this series is that reconciliation architectures are largely independent of business domain.

Only the data changes.

The architecture remains unchanged.

Only the source systems and business rules differ.

This explains why many enterprise reconciliation platforms can be configured for different business domains without changing their core engine.

2.6 Reconciliation Is More Than Matching

#

Many newcomers believe reconciliation simply means matching two files.

Matching is only one step.

A complete reconciliation platform also performs:

• Data acquisition
• Data standardization
• Record matching
• Field comparison
• Break classification
• Workflow management
• Investigation
• Resolution
• Audit
• Reporting

Matching is therefore a component of reconciliation, not reconciliation itself.

Chapter Summary

#

In this chapter, we developed a universal architecture that applies to reconciliation systems across the BFSI industry. We showed that, despite differences in business domain, every reconciliation platform follows the same logical sequence: collecting data, normalizing it, matching corresponding records, comparing values, classifying differences, resolving exceptions, and maintaining an audit trail. This perspective allows us to understand reconciliation as a reusable architectural pattern rather than a collection of isolated business processes.

Key Takeaways

#

• Every reconciliation system follows the same logical architecture.
• Business domains differ primarily in their data and business rules, not in the reconciliation process itself.
• Matching records is only one stage of reconciliation.
• Effective reconciliation requires normalization, comparison, break classification, resolution, and auditing.
• Understanding the architecture is more valuable than memorizing domain-specific reconciliation workflows.

Looking Ahead

#

So far, we have answered two fundamental questions:

• Why does reconciliation exist?
• How are reconciliation systems architected?

The next question is equally important:

What are the fundamental building blocks that every reconciliation process uses?

In Chapter 3, we will introduce the common vocabulary—Matching Keys, Business Rules, Tolerances, Breaks, Exceptions, Materiality, and Audit Trails—that appears in every reconciliation system, regardless of industry.

See the series roadmap for the full ten-part reading path.

Also in this series: Understanding Reconciliation: Why Financial Systems Must Agree (Part 1). Next: Core Concepts and Building Blocks (Part 3).