Based on the work I have done on reconciliations for some of the largest investment banks in the world, including those in America, Canada and the UK I'm convinced that there is room for improvement in the way that Operations and Financial Controls are implemented.

Typically, there will be a team of product managers, or operations control people or operations engineering people working with colleagues in IT  to define extracts from Front Office, Middle Office and Back Office Settlement and Sub Ledger Systems. These data extracts will be based on their own appreciation of the economic data associated with specific types of trade or position or cashflow.

On the other side of the reconciliation the data could be being extracted from another Sub Ledger system or it could be arriving on the SWIFT network from a trading counterparty or from an Agent or a Custodian.

Custodians, Agents and SWIFT themselves are more likely to be providing data in some kind of standard format. For example the majority of Custodians can send SWIFT MT536 statements for trades across a Fixed Income Trading account. Given that SWIFT mandates the structure of the MT536, all the economic data is already present, and the only repair that may be required would be if the underlying security identifier is not one of the more common ones, for example ISIN. Other repairs may be required but the security identifier repair is the most common one.

On the so called "Ledger" side of the reconciliation against a Statement, there is no obligation on the in-house IT development team to produce a pseudo SWIFT MT536 out of their Fixed Income sub ledger system, and indeed in my experience proprietary systems that run on mid-range technology platforms  are not easily configured to produce a valid SWIFT statement message, largely because few custodians or agents would use mid-range hardware based systems for business as Custodian for an Investment Bank. The custodians are more likely to have a large proprietary mainframe system and a team of support staff to ensure that their statements are SWIFT compliant.

Given that any "Industry Standard" message can comprise 10 or fewer mandatory elements or as many as 100 or more, it is easy to see that there is a potential gap between what you could reconcile between Sub Ledger and Statement or between "Our" confirmation and the trading counterparties. This is particularly true of the OTC market. But the problem can also occur within a single organisation with disparate Sub-Ledger systems for the same asset class that have been purchased on different dates by different legal entities before the banking "Group" was finally formed by acquisition or merger.

There are cases in the market where a single large UK, Swiss or American Bank has more than one subsidiary that trades with other entities in the same group on an OTC basis where there is no simple match between the messages which represent the same trade and is exchanged between them without matching.

A simple, and if I dare to say elegant, solution to this problem is to introduce a transformation process quite early in the lifecycle of the building of the control. So, when an Ops Control person defines the list of elements to be extracted from the sub ledger, it would be beneficial if he could run this model through a tool that understands the data and transforms it into the nearest equivalent industry standard message - so for Bond Trades this would be FIXML version 5.x and the sub schema would be the Trade Capture Report. It is then relatively simple to take each message thus constructed and push it through a schema validator, and then read through any resultant validation errors. It may be necessary to loop around this process a number of times until the definition of the extract is perfected - ie the extract contains sufficient data to construct a bona fide FIXML message. This would ensure that the control is being based on sufficient information as would be needed to exchange an industry standard message with the trading counterparty.

Obviously FIXML is not extensive enough to cover all asset classes, but other standards such as FPML, SWIFT and ISO20022 are being developed and will eventually allow us to use standard schema validation on all data flows into all banking operations and financial controls reconciliations, so that at least we can be sure we really do have all the necessary economic data for the reconciliation before we start to finalise the matching logic and identify and remediate the breaks.