6 ms·

Common Problems in Financial Services Reconciliation

101 points by kunle 6y ago

doonesbury 6y ago
Consider the case of a trader (trading firm) with a custodian bank. What's the best way to reconcile the custodian's view with one's own trading system and its backend? Recall this is important because, as the custodian does settlement, the trader doesn't want to purchase instruments with cash the custodian doesn't think it has nor purchase shares the custodian bank thinks it already has. Keeping these two matched is a real, pressing, daily problem. Blockchain I think is an impractical, over-hyped solution that has no purchase in Fintech or even classical finance.
- polack 6y ago
  Generally speaking it's not possible to get the data needed from the custody during the day. In the evenings/nights when they have done all settlements, cleaned up the data and executed their batch jobs they can send you their view of things in the form of positions and transactions. From there it's easiest to start comparing positions and if they deviate then have the system match everything that has happened in both systems since they last matched in order to find the faulty transaction(s). After that you should be ready for the next business day, where you have to keep track of how the state is affected by your trades and other events during the day. Then the cycle repeats.
- Galanwe 6y ago
  Don't forget that there is a third layer of middle office in between. So actually there is front -> middle -> back that should reconciliate on the current portfolio positions
mianos 6y ago
This paper was 100% of my life for a few years at spriggy. One of the lines that almost made me spit my coffee with a laught was "that allows you to tie out balances and payments with zero failures (this is super unlikely)." Building stock exchanges for 13 years before my time in consumer finance I'd say financial trading systems are a dream environment compared to post trade settlement and settlement is a dream compared to banking. Specially when you have multiple sources of truth, as described in this paper.
- kunle 6y ago
  The funny thing about this comment is everyone whose read this but hasn't dealt with this problem is super confused that it even exists. Immediately after reading this, a colleague asked: "How can a balance ever be not the sum of the transactions ?" Which elides the fact that differing transactions have different states they can be in (and different levels of immutability). But once you get in the weeds dealing with this stuff is a real pain.
  - noizejoy 6y ago
    You should have added a “trigger warning” to your submission - as a courtesy to those of us, who’ve experienced and then escaped that world. :-)
    - doonesbury 6y ago
      Right ... the underlying issue here is that we have N entities each with their own IT systems. There is a serious and direct dependency between them in order to carry out daily trading as my custodial example shows. The way out is to have a realtime event feed between the two which requires a common serialization format, securityIds, accounts, etc. etc. Not even JPM or BNY has this so far as I know on the custodian side before we even entertain what trader X's company might have. Therefore what tends to happen is ETL's where some middle-system imports the trader's and custodian views and tries to reconcile. Note these views are often only available after batch processes run at the end of the day ... The problems are ... tons: - Even FIX/Swift etc. messages are prone to incomplete interpretation and mis-usage the latter hard to change once it's baked in. Setting up yet another format is a huge ask. - Each end of the work invariably has a slightly different data model so even if one did get the data it's not like there's a memcmp of two structs at the bottom somewhere - As I say blockchain w/ POW is not only slow, there are oodles of privacy concerns. And even if you tech'd that out blockchain would be a Merkle wrapper of something like a CSV/FIX/Omgeo/Swift message ... and what's the point then of all that crypto nonsense? Better to have a direct HTTPs connection, and skip the crypto work. However, if counter-parties could somehow get messages from the exchange at the time the trade is done and forwarded something to the trader and counter-party (granted encroaching on the some $100 billion/yr custodian business) that might help. Indeed, other writers here make a good point: trading through exchanges is nice. Post-trade sucks.
contingencies 6y ago
Try writing a digital asset exchange to interface with numerous, rapidly evolving settlement systems and asset types as well as all the conventional banking issues, then make it cross-jurisdiction and throw in some rewinds / split chains / client forks and motivated attackers for extra fun. That was the situation starting Kraken. More thoughts at https://raw.githubusercontent.com/globalcitizen/ifex-protocol/master/draft-ifex-00.txt https://raw.githubusercontent.com/globalcitizen/ifex-protoco...
gregdoesit 6y ago
"Even at scale, not all financial technology companies manage their own ledger. Many don’t." This was surprising for me to hear. Yes, it's a lot of work to build and manage your own ledger, but I'd think it's a core capability at FinTech? When I worked at Uber, we built/managed our own ledger there. Operating with dozens of PSPs, many of them settling in bulk, on a less frequent basis, I'm not sure it would have been feasible not do so so.
- kunle 6y ago
  I was surprised to hear it too tbh. Chime for instance doesn't have one (last I checked). I think what happens is, you don't build it if its not strategic in the early days, and then if you hit escape velocity there's never a good time to build one.
gomezjdaniel 6y ago
Do you have other interesting readings on this topic? :)
- kunle 6y ago
  Unfortunately not. It's a weird topic with no reference content when we were working on recon at Cash App, which is why I wrote the essay. If you find anything on it, let me know.

101 points by kunle 6y ago

Consider the case of a trader (trading firm) with a custodian bank. What's the best way to reconcile the custodian's view with one's own trading system and its backend? Recall this is important because, as the custodian does settlement, the trader doesn't want to purchase instruments with cash the custodian doesn't think it has nor purchase shares the custodian bank thinks it already has. Keeping these two matched is a real, pressing, daily problem. Blockchain I think is an impractical, over-hyped solution that has no purchase in Fintech or even classical finance.

polack 6y ago
Generally speaking it's not possible to get the data needed from the custody during the day. In the evenings/nights when they have done all settlements, cleaned up the data and executed their batch jobs they can send you their view of things in the form of positions and transactions. From there it's easiest to start comparing positions and if they deviate then have the system match everything that has happened in both systems since they last matched in order to find the faulty transaction(s). After that you should be ready for the next business day, where you have to keep track of how the state is affected by your trades and other events during the day. Then the cycle repeats.
Galanwe 6y ago
Don't forget that there is a third layer of middle office in between. So actually there is front -> middle -> back that should reconciliate on the current portfolio positions

mianos 6y ago

This paper was 100% of my life for a few years at spriggy. One of the lines that almost made me spit my coffee with a laught was "that allows you to tie out balances and payments with zero failures (this is super unlikely)." Building stock exchanges for 13 years before my time in consumer finance I'd say financial trading systems are a dream environment compared to post trade settlement and settlement is a dream compared to banking. Specially when you have multiple sources of truth, as described in this paper.

kunle 6y ago
The funny thing about this comment is everyone whose read this but hasn't dealt with this problem is super confused that it even exists. Immediately after reading this, a colleague asked: "How can a balance ever be not the sum of the transactions ?" Which elides the fact that differing transactions have different states they can be in (and different levels of immutability). But once you get in the weeds dealing with this stuff is a real pain.
- noizejoy 6y ago
  You should have added a “trigger warning” to your submission - as a courtesy to those of us, who’ve experienced and then escaped that world. :-)
  - doonesbury 6y ago
    Right ... the underlying issue here is that we have N entities each with their own IT systems. There is a serious and direct dependency between them in order to carry out daily trading as my custodial example shows. The way out is to have a realtime event feed between the two which requires a common serialization format, securityIds, accounts, etc. etc. Not even JPM or BNY has this so far as I know on the custodian side before we even entertain what trader X's company might have. Therefore what tends to happen is ETL's where some middle-system imports the trader's and custodian views and tries to reconcile. Note these views are often only available after batch processes run at the end of the day ... The problems are ... tons: - Even FIX/Swift etc. messages are prone to incomplete interpretation and mis-usage the latter hard to change once it's baked in. Setting up yet another format is a huge ask. - Each end of the work invariably has a slightly different data model so even if one did get the data it's not like there's a memcmp of two structs at the bottom somewhere - As I say blockchain w/ POW is not only slow, there are oodles of privacy concerns. And even if you tech'd that out blockchain would be a Merkle wrapper of something like a CSV/FIX/Omgeo/Swift message ... and what's the point then of all that crypto nonsense? Better to have a direct HTTPs connection, and skip the crypto work. However, if counter-parties could somehow get messages from the exchange at the time the trade is done and forwarded something to the trader and counter-party (granted encroaching on the some $100 billion/yr custodian business) that might help. Indeed, other writers here make a good point: trading through exchanges is nice. Post-trade sucks.

contingencies 6y ago

Try writing a digital asset exchange to interface with numerous, rapidly evolving settlement systems and asset types as well as all the conventional banking issues, then make it cross-jurisdiction and throw in some rewinds / split chains / client forks and motivated attackers for extra fun. That was the situation starting Kraken. More thoughts at https://raw.githubusercontent.com/globalcitizen/ifex-protocol/master/draft-ifex-00.txt https://raw.githubusercontent.com/globalcitizen/ifex-protoco...

gregdoesit 6y ago

"Even at scale, not all financial technology companies manage their own ledger. Many don’t." This was surprising for me to hear. Yes, it's a lot of work to build and manage your own ledger, but I'd think it's a core capability at FinTech? When I worked at Uber, we built/managed our own ledger there. Operating with dozens of PSPs, many of them settling in bulk, on a less frequent basis, I'm not sure it would have been feasible not do so so.

kunle 6y ago
I was surprised to hear it too tbh. Chime for instance doesn't have one (last I checked). I think what happens is, you don't build it if its not strategic in the early days, and then if you hit escape velocity there's never a good time to build one.

gomezjdaniel 6y ago

Do you have other interesting readings on this topic? :)

kunle 6y ago
Unfortunately not. It's a weird topic with no reference content when we were working on recon at Cash App, which is why I wrote the essay. If you find anything on it, let me know.