One of the things I designed and built 20+ years ago was a middleware layer that took transactions, accounts and products, (TAP) and distributed them on a broadcast basis, so receivers subscribed to required data, and published any and all events they generated.
This middleware layer is still in place today in the bank.
It’s use meant you could build a system with a subscriber/publisher pair. The subscriber would fulfil the data based on a subscription, with a set of simple rules. And the new system would publish events it created for other subscribers to use.
Tackling the core data for an investment bank, and making it a service rather than a repeated chore, removes the risk of development, reduces system build overhead, removes reconciliation gaps and simplifies the entire technology management process.
Investment Banking is a simple business. Whether transacting simple cash products or complex structured products, all core transactions are made of three items, accounts, products and current value. Even the value is transient, and needs to be derived from the product.
Positions are generated from the cumulative effects of transactions, and can have both securities and cash postings against a position, which are just events.
Once you define the elements of each product, at a base model level, then re-use that same product across all systems. Don’t repeat the product store, or reproduce it elsewhere. Centralise it, manage it once, distribute it.
Ideally for the market based products (Equities, Bonds, Listed Derivatives), take a market feed. Don’t setup and manage market products in-house. Take them from the market, centralise them, distribute internally.
For accounts, whether external clients, or internal books, these should also be centralised, managed once, and distributed.
In todays tougher regulatory controls, KYC is now critical. (It always was but now you get fined if you don’t deal with it !!!).
Spreading accounts over multiple systems, all manually input directly into the system, even partially is just asking for trouble. Someone will make a mistake, and you will have clients on front-end systems you shouldn’t be trading with, but you are….. So fix the problem, before you get fined, and then have to fix the problem.
Having sorted a single source of Client data, with credit limits, KYC flags, tradable product mappings, market name maps, entity structures, … – feed this to all your systems.
Don’t get confused – you don’t need to sort CRM out in this process. The moment you cross that line, there is a whole different set of issues. BUT your core data should be the source of client data to your CRM, and only clients fed from this should be in the CRM, and talked to on behalf of the bank.
The old adage of “prospects are not clients” no longer applies. Trying to sell something to someone makes them a client, even if they don’t buy it. You are still having a market interaction, and your regulator will still want to know why you didn’t know he was on a blacklist !!!
Internal Books are just client accounts, they are internal client accounts. And should be marked as such. And treated as such. Generating profit by client, can show you profit by internal client too. And this is useful information. Having escalation for unmatched positions on clients, applies as much to internal books, and critical information. So treat “books” as clients. Have one book structure across the whole firm, and centralise it, manage it once, distribute it.
Having sorted your core data, transactions are just a combination of two accounts, one or more products, a trade owner (often driven off the product), a sales owner (often driven off the client), and a current value.
Note the value of the transaction as “done” is done. But the value of the open positions generated by one or more transactions will change in value, and risk will then change with that value.
For cash positions, such as Equities or Bonds, the value will change based on market value, mark-to-market. But the open positions will also change in value due to market events, fed from your central source of market events, based off your product database. Dividends, Coupons, Margin Calls, … will change the value of a position. (Note a position is the result of a series of one or more transactions).
More complex products, which are made of a number of underlying products, have a value derived from the current value of those underlying products, and often a cash projection against those products. Same principals apply though.
Where the process gets too bogged down is in trying to define the ultimate data model for this. Don’t.
Define what you know, and leave flexibility for what you don’t. Spending months on every variation of every product, account, entity, etc, just delays the process. Anyone having worked in a bank for 10+ years, should be able to define the main components of client, product, transactions, positions, …. So use the experience, and take that as the starting data model.
There is no silver bullet, and all the tech buzzwords don’t solve the issue that there are transactions made of accounts (clients, books), and products (securities, structures) that create events (booking, settlement, margin call, payment….).
This is not rocket science. We are not saving lives, or getting to the moon, we are moving dollars from A to B. So simplify the data, and clean up the reconciliations, reporting, P&L accuracy, risk values etc.
Then go to the pub.