Reconciliation

A white paper on reconciliation needs and best practices

Jan 23, 2023 by Debapriya Bhattacharjee

   

 

Reconciliation is a process where two or more transactions are compared to check their transaction economics are in concurrence with each other. This is done by examining the relevant data and making sure that all the data is consistent, accurate and complete across all systems. Any discrepancies or occurrences of transactions not reconciling or matching should be investigated to ascertain the cause.

All reconciliations are performed at the account level. One account will receive a debit and the other account will receive a credit. This is called ‘double-entry accounting’ and is one of the most popular ways of reconciling accounts. In double-entry accounting, every financial transaction is posted in credit and debit accounts.

Reconciliation is performed by businesses for the following reasons:

  • To avoid paying more than required
  • To check the accuracy of transaction figures
  • To avoid undetected unauthorized transactions
  • To supervise the progression of a transaction
  • To impede a transaction at the right time, thereby reducing future financial exposures and risks

 

Client needs

Two–way reconciliation

All banks perform several workflows throughout the day to meet their daily business needs.

Data discrepancies are very common when data entries are made manually. While performing such workflows, data usually moves from one system to another. In such cases, banks would like to ascertain that the data quality is consistent across all systems. Here, reconciliation is a useful tool to compare trade economics and ensure they agree.

For any reconciliation project, clients prefer to have the below features:

  • Feeds should be loaded in an automated manner 
  • Matching is expected to be run in any of the following ways:
    • When both side files are loaded successfully 
    • At a predetermined time of the day
    • Manually by a user 
  • Data cleansing should be a feasible feature while loading the data for a better system match rate
  • Filtering out unexpected and redundant data is expected in order to avoid any data breaks in the system
  • Data preprocessing while loading the data is a very common ask. This helps to identify cases where there is an issue with the data or if any data manipulation is required (such as aggregating a few transactions into a single transaction, splitting very large files into smaller files, etc.)
  • In case user authorization is required at any step, dual approval (maker-checker) is needed by the client. Approval access should be available to limited users 
  • Automated reconciliation reports featuring matched and unmatched transactions 
  • Tolerance may be expected in cases where several data attributes are needed to match 
  • Data masking might be required in production systems to avoid any PII data breaches 
  • There are scenarios when a source system might request for a matched status to be sent back after matching

 

Three-way reconciliation

There are also scenarios where an intersystem reconciliation is needed between three systems. The reconciliation report is used to identify any missing or additional data between the three systems.

Clients prefer the below features in a three-way reconciliation project:

  • Feeds from all three systems should be loaded in an automated manner
  • Matching rules are based on the system identifiers, which should be identical across all three feeds 
  • Matching can be triggered at a fixed time, manually by the user, and by the system when all three feeds have loaded successfully
  • Matching breaks must be categorized into different buckets for three-way reconciliation e.g., if a trade is missing from one of the three feeds, it goes to a certain match bucket. If a trade is missing from two feeds and present in only one feed, it goes to a different match bucket. This kind of categorization help users understand the breaks in a better way
  • The outstanding data should be investigated daily and actioned 
  • In certain cases, breaks are investigated and actioned outside the system. Here, the outstanding data needs to be housekept by the system. This housekeeping process can be automated as per the client’s requirements 
  • Recon reports can be customized as per client requirements e.g., number of columns, field names
  • Recon reports can be archived as per client requirements

 

Industry best practices

Here are 10 industry best practices followed by reconciliation units of financial organizations:

  • Ensure reconciliation is done daily and outstanding items are reviewed 
  • In case of data breaks, there should be a fixed time in which the exception is resolved 
  • A minimum amount of transaction data attributes is required to complete the reconciliation process. These attributes ensure the completeness of the data to be reconciled e.g., the date, amount or quantity should be the same or within an acceptable tolerance
  • Ensure that sensitive data is well-masked and encrypted to protect it from being exposed
  • Reconciliation should be done within the same account 
  • References used to identify accounts should be the same or have predefined, recognizable, unique identifiers
  • In case a user requires authorization, a dual approval mechanism should be in place
  • Reconciliation feeds should be loaded automatically as and when they arrive, or in batches
  • Reconciliation should be scheduled/triggered based on a predetermined time/event
  • Reconciliation reports should be generated automatically and be available to the users for verification

  

DOWNLOAD PDF VERSION

For more Banking and Capital Markets insights, see Luxoft on LinkedIn

quotes background

News and insights

blog

Monetize the customer data you didn’t even know you had

Blog

Monetize the customer data you didn’t even know you had

blog

Are you up to speed with post-trade payment processing?

Blog

Are you up to speed with post-trade payment processing?

blog

Why as-a-Service operating models are the future of banking technology

Blog

Why as-a-Service operating models are the future of banking technology