Chapter 3: The Language of Reconciliation

#

Part 3 of the Reconciliation Systems in BFSI series

Understanding the Fundamental Building Blocks of Every Reconciliation System

3.1 Introduction

#

Imagine two experienced reconciliation analysts discussing a production issue.

One analyst says:

“The matching key is wrong.”

Another replies:

“No, the business rule is correct, but the tolerance is too strict.”

A third adds:

“The transaction matched, but it still generated a break because of a reference data exception.”

To someone new to reconciliation, this conversation sounds confusing.

Yet every reconciliation process—whether in banking, payments, lending, insurance, capital markets, or alternative investments—uses the same vocabulary.

Before learning different reconciliation types, we must first understand this common language.

These concepts are the building blocks from which every reconciliation system is constructed.

3.2 Business Event

#

Everything begins with a Business Event.

A business event is something that actually happens in the financial world.

Examples include:

• Customer deposits money.
• Customer withdraws cash.
• Loan is disbursed.
• EMI is collected.
• Stock is purchased.
• Bond coupon is paid.
• Insurance premium is collected.
• Insurance claim is settled.
• Capital call is issued.
• Dividend is distributed.

Without a business event, there is nothing to reconcile.

Everything else in this chapter ultimately refers back to this event.

3.3 System Representation

#

Every participating system creates its own record of the business event.

For example:

Business Event

Buy 100 shares of ABC Ltd.

↓

Trading System
Buy 100 shares

↓

Portfolio Accounting
Asset Added

↓

General Ledger
Journal Entries

↓

Risk System
Exposure Updated

↓

Custodian
Position Recorded

Each record is called a System Representation.

Although they describe the same business event, they are optimized for different business purposes.

3.4 Source System

#

A Source System is any system that provides data for reconciliation.

Examples include:

A reconciliation process may involve two, three, or many source systems.

3.5 Matching Keys

#

One of the most important concepts in reconciliation is the Matching Key.

A matching key answers a simple question:

Which records belong to the same business event?

Suppose two systems contain these records.

The matching engine concludes:

These two records probably represent the same trade.

Sometimes a single field is sufficient.

Sometimes multiple fields must be combined.

Example:

Portfolio
+
Trade Date
+
Ticker
+
Transaction Type
+
Currency

Together they uniquely identify a transaction.

This combination is called a Composite Matching Key.

3.6 Matching Rules

#

After identifying corresponding records, the reconciliation engine applies Matching Rules.

Examples:

• Trade IDs must match exactly.
• Currency must be identical.
• ISIN must match.
• Portfolio must match.
• Transaction Type must match.

If these conditions are satisfied, the records are considered matched.

Notice that matching does not yet determine whether the transaction is correct.

It only establishes that the two records refer to the same business event.

3.7 Comparison Rules

#

Once records have been matched, their attributes are compared.

Typical comparisons include:

• Amount
• Quantity
• Price
• Interest
• Fees
• Settlement Date
• Exchange Rate
• NAV

Comparison answers questions such as:

Is the amount equal?

Is the quantity equal?

Is the settlement date identical?

Comparison is therefore different from matching.

Matching identifies corresponding records.

Comparison evaluates whether those records agree.

3.8 Business Rules

#

Not every comparison is a simple equality check.

Organizations define Business Rules describing how reconciliation should behave.

Examples:

• Ignore transactions below ₹1.
• Settlement date may differ by two business days.
• Corporate actions require manual review.
• Futures MTM differences should remain open until monthly settlement.
• Missing dividends older than three days must be escalated.

Business rules transform reconciliation from a technical comparison into a business process.

3.9 Tolerance

#

Financial systems often accept small differences.

Suppose one system calculates:

100.004

Another calculates:

100.005

The numerical difference is only 0.001.

Investigating such tiny differences would waste operational effort.

Instead, organizations define Tolerance.

Examples:

• ± ₹0.01
• ± $1
• ± 2 business days
• ± 0.001 units
• ± 0.01%

If the difference falls within the tolerance, it is treated as acceptable.

3.10 Break

#

A Break is a difference that violates the reconciliation rules.

Examples:

• Missing transaction.
• Wrong amount.
• Duplicate record.
• Incorrect currency.
• Incorrect settlement date.
• Wrong quantity.

Not every difference is a break.

Only differences that exceed the defined business rules become breaks.

3.11 Exception

#

An Exception is a break that requires investigation or action.

Examples:

Missing Trade

↓

Investigate

↓

Book Trade

↓

Resolved

Exceptions enter operational workflows.

Analysts investigate them until they are resolved.

3.12 Resolution

#

Resolution is the process of removing the exception.

Possible actions include:

• Book missing transaction.
• Reverse duplicate transaction.
• Correct reference data.
• Update exchange rate.
• Wait for settlement.
• Contact broker.
• Contact custodian.
• Contact client.

Every resolution must be recorded.

3.13 Audit Trail

#

Financial institutions must demonstrate:

• When the break occurred.
• Who investigated it.
• What decision was made.
• Who approved the resolution.
• When it was closed.

This historical record is called the Audit Trail.

It supports governance, compliance, and regulatory inspections.

3.14 Materiality

#

Not every break has the same importance.

A ₹0.02 difference and a ₹20 million difference should not receive identical attention.

Organizations therefore define Materiality.

Materiality helps determine:

• Investigation priority.
• Escalation level.
• Management reporting.
• Regulatory reporting.

This allows operations teams to focus on the most significant risks first.

3.15 Bringing Everything Together

#

We can now describe every reconciliation process using the same language.

Business Event

↓

System Representations

↓

Source Systems

↓

Matching Keys

↓

Matching Rules

↓

Comparison Rules

↓

Business Rules

↓

Tolerance Check

↓

Break

↓

Exception

↓

Resolution

↓

Audit Trail

This sequence forms the vocabulary that will appear repeatedly throughout the remainder of this series.

Chapter Summary

#

This chapter introduced the common language of reconciliation. Rather than treating reconciliation as a collection of unrelated operational activities, we defined the core concepts—Business Events, System Representations, Source Systems, Matching Keys, Matching Rules, Comparison Rules, Business Rules, Tolerances, Breaks, Exceptions, Resolutions, Audit Trails, and Materiality—that describe every reconciliation process. With this vocabulary in place, we are now ready to explore how these concepts are applied across different sectors of the BFSI industry.

Key Takeaways

#

• Every reconciliation begins with a Business Event.
• Independent Source Systems create their own System Representations of that event.
• Matching Keys identify which records belong together.
• Matching Rules determine whether records correspond to the same business event.
• Comparison Rules evaluate whether matched records agree.
• Business Rules define acceptable behavior beyond simple equality.
• Tolerance prevents insignificant differences from becoming operational issues.
• Breaks identify meaningful inconsistencies.
• Exceptions are breaks requiring investigation.
• Audit Trails ensure transparency, compliance, and accountability.

Looking Ahead

#

We now have the conceptual foundation required to understand reconciliation in any financial domain.

Beginning with the next chapter, we will apply this common vocabulary across the BFSI industry. We will examine how banks, payment processors, lenders, insurers, asset managers, capital market participants, and alternative investment firms all solve fundamentally the same reconciliation problem while adapting the matching keys, business rules, and operational workflows to their specific business needs.

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

Also in this series: The Universal Reconciliation Architecture (Part 2). Next: Types of Reconciliation Across the BFSI Industry (Part 4).