Traditional way of processing corporate action events in large custodian banks
Traditionally, large custodian banks had multiple position keeping systems and asset servicing systems that were servicing their different entities. In some cases, the systems were different and used multiple technologies and were specifically sourced or developed for a specific market. The biggest drawback of this decentralization model was that the same event was being processed multiple times across all the different entities of the same bank. This leads to processing inefficiencies and duplication in the asset servicing value chain, which also increases the number of FTEs, reduces the controls, and increases the risk. The nature of this process has resulted in the end client receiving a late announcement of an event and an (inferior) early election deadline and losing investment opportunities.
From a corporate actions processing perspective, there are multiple ‘to and from’ flows between the Global Custody (GC) client accounts and the intermediate accounts at the Local Custody (LC) entity. These flows include:
The diagram below depicts the overall flow of the corporate actions data between events of different entities using a hub and spoke model.
In the above illustration, three separate events are created, each processed independently. The application ecosystem around these three events, as well as the operations teams, can be different. There is significant duplication of efforts in managing event data. The operational processes/tasks/controls are also separate owing to different processing systems and operations teams. The inter-entity flows are typically managed through ISO 15022 standard messages. Any break in Straight-Through Processing (STP) leads to a considerable lag for the end client to receive the announcement as well as inferior deadlines (In this case, the HK and GB Clients) being set. In summary, this model is inefficient and creates far too many duplicated processes, needing increased operational control and management oversight, which leads to a potential increase in operational and reputational risks.
What is single-event processing?
Single-event processing ensures that a corporate actions event affecting different positions, businesses, and entities is processed only once. A single event per a street-facing agent enables a global custodian or bank to manage all entitled positions across all branches. The entire “Hub & Spoke Position” stock record model is merged into a set of positions under a single event.
TCS BaNCS solution
In a solution like TCS BaNCS, all the accounts, including the intermediate/ linked/omnibus accounts of a typical hub and spoke, will be replicated under one legal entity “G” – representing global. The office id would represent the branch/legal entity that the bank has in its account structure. There will be internal routing (within TCS BaNCS) for the announcement, election, and payment messages affecting the intermediate accounts maintained in different branches or entities (In the diagram above, intermediate/ linked/ omnibus accounts are shown in Blue). TCS BaNCS will send/receive the messages to/from the final client and street agents. The necessary Bank Identifier Code (BIC) transformation is performed in the system to send the messages to end clients, reflecting the actual BIC of the entity to which the client belongs.
Single-event processing:
Key dependencies
While it’s possible to establish an operating model for single-event processing using TCS BaNCS, there are some upstream and downstream dependencies that need to be considered, which are summarized below:
While more global custodian banks are trying to innovate with newer business/ technology models to provide better client servicing and reduce operational costs, TCS’ unique proposition of single-event processing leveraging TCS BaNCS for Corporate Actions can help achieve these objectives easily.
Single-event processing ensures that a corporate actions event affecting different positions, businesses, and entities is processed only once.