Do you have the right Back-Office? Part I
This is an introduction to a series of articles that will go through detailing the Back-Office modules used for Treasury and Capital Market operations.
It will be published in several parts, since the subject is too long to handle in one publication.
What is a Back-Office
First let us define what is a Back-Office in Treasury and Capital Markets:
Typical functions include settlement (with all the features that it entails) of cash, securities and derivatives including FX and commodities, reconciliations, issuance of new securities through Initial Public Offerings (IPOs), and processing of asset servicing.
At its center is the core function of clearing and settling trades.
Lately the Back-Office had a big push from regulator in its compliance, anti-money laundering and risk management activities. The knowledge requirements to run back-office operations evolved, these new changes have brought excitement and forensic glamour to the back-office.
(refer to the publication “Goodbye Back-Office 1.0 and welcome Back-Office 2.0”).
The back-office department may not be where banks make their profits, but it is certainly where they can lose them.
The more standardized and efficient a bank is at conducting its back-office business, the greater the percentage of revenues that will feed into the bottom line. Errors in the processing of a firm’s transactions can be particularly costly (in terms of money and reputation), which is why the risk management and control functions performed by the operations team are so critical.
Generic Solution
Whereas as Front-Office solutions are assets class specific, a Back-Office solution should be a cross asset “generic” solution completely agnostic from the front-end trading platforms.
A Back-Office solution does not need to understand a product type, or the analytics pertained to evaluate a specific product.
It needs to understand:
Trade economic data: date of trade, value date, type of trade…
Static data: legal entity, counterparts, SSI, …
Trade life cycle events: novation, exercise, prolongations, terminations, …
Cash flows message: amount, conventions, currencies, dates, …
Settlement message [physical or cash]: amount, conventions, currencies, dates, …
Posting message for feeding the general ledger
Exposure messages for clearing and collateral purposes
The back-office solution is not intended to do any product evaluation, it inherits NPV, capital gains, exposures, … from connected front-office systems.
Also, it is not intended to be the General Ledger, it should generate the postings as a sub-ledger.
Core of a Back-Office solution
In a nutshell a good Back-Office solution needs to:
Rely on a standardized Operating Model [SOM] (no need to reinvent the wheel)
Rely on a very strong workflow for every object’s life cycle like: trades, legal entities, messages, documents, …
Use strong automation and scripting mechanism
Use strong and flexible reporting
Have excellent dashboards for monitoring
Support large volumes and large burst of data (never know when there is a crash)
Have good segregation of data when needed (multi-entities, multi-tenants, …)
Have good API for interfacing
In my next article I will list and describe in detail each module used in a back-office to give a better understanding for companies either building, buying or implementing a solution.
#CapitalMarket #Treasury #BackOffice #Banking #banks #regulations