Common Problems in Financial Services Reconciliation | Hacker News Reader

Common Problems in Financial Services Reconciliation

kunle.app

101 pointskunle22 comments

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.

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.

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. :-)

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.

lol - everything you say is right and eloquently stated!

My over-simplified version would just say “precise communication of even moderately complex facts is incredibly hard”.

And that’s human to human communication, of which system to system communication is arguably just an implementation.

Arguably even communicating with ourselves over stretches of time is non-trivial as experienced by anyone who has ever found a paper note or maybe a comment in code by one’s younger self only to scratch our head and wonder “wtf did I mean by that?”

yep

In your opinion, where is the most room for improvement in post trade ops, including clearing and settlement? How do you disrupt those entrenched parties that aren’t too enthusiastic about system efficiency improvements?

Shameless plug: the problems that you describe are almost exactly what we're trying to solve with DAML and Canton [1]. From the Canton whitepaper:

Building distributed applications that involve multiple organizations is hard with today’s technology. For each application, all organizations must agree on the data encoding, transport mechanisms, and interaction rules, and all must implement their part of the interaction correctly, including authentication and authorization. Once implemented, such an application often becomes a silo: there is no general convenient, secure and privacy-preserving way to integrate such applications and compose the business workflows that they automate.

The big problem is bootstrapping the network; as you say, setting up yet another format (DAML in this case) is a huge ask. But we're starting to see the beginnings of a network, as in the next couple of years the Australian [2] and north-bound (i.e., mainland China) Hong Kong securities [3] will be accessible through DAML.

[1]: https://canton.io [2]: https://www2.asx.com.au/markets/clearing-and-settlement-serv... [3]: https://www.ledgerinsights.com/hkex-daml-smart-contract-stoc...

Some financial service providers (i.e. those who do NOT buy low sell high) might try to move into the custodial market. Assessing the risk there is beyond my pay grade I don't know how smart that'd be ... but we can observe it's not common. If that did happen clients could use that provider's IT system to do trading and voila since all data is at one provider, some kinds of reconciliation is easier. In short, market consolidation.

There's tactical steps too that can partially overcome the independent IT systems, say, getting the custodian to send data realtime, sending it realtime on the trader's behalf to the recon entity ... I'm not sure what custodial service provides think about that ... presumably they would if they could probably hampered by their own IT systems like the rest of us.

The final approach is what appears immediately above: traders and custodians --- generally any set of business entities N who need to compose data --- publish to a virtual shared DB. I'm gonna read the white papers and follow-up afterwards.

I don't have a financial services background myself, so assessing I can't really comment on the risk of consolidating custodianship and trading. But market consolidation will at some point run into legal and jurisdictional limits (data sovereignty), if not other ones first (do I really trust that giving you all this data doesn't give you an edge?). The idea behind the virtual shared DB is that you don't have to outsource the data, but you can still transact (with strong consistency) over data shared with many entities.

Like I said, I don't have a background in financial services myself, but there are people on my team who have vowed to never have to do reconciliation again. As you seem to wear the same scars, I'm very curious to hear your thoughts on the whitepaper based on your other good comments in the thread. Feel free to e-mail me (address in profile) or post here.

The chance of replacing every banking system at once is not at all possible. Even just replacing CHESS all at once is pretty much impossible. Just how many years late is it and how many more until it's actually used by all participants?

The idea is not to replace every banking system, but to create a network with a sufficient technological edge over existing solution and sufficient business value.

CHESS is definitely a complex beast. The go-live date has moved from 2021 to 2023, AFAIK at the request of the participants. To your question when it will be directly (as in, through DAML) used by all participants - I guess at the point where it generates enough value that it's advantageous for them to use it.

Yeah, definitely some PTSD

I see a blog post, what paper are you referring to?

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.

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.

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

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-protoco...

"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.

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.

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

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.

Reply on news.ycombinator.com