Automating securities trade reconciliation process
Work executed for a Prime Broker operating on New York Stack Exchange
Settling for success
Failed trade occurs if either buyer or seller fails to deliver the securities or cash it promised on the settlement date. When this happens, a side that failed to deliver could face serious consequences - financial losses, fines, and damage to the reputation.
Usually, each broker has to keep a dedicated team of experts, working 24h on monitoring the process, detecting discrepancies and potential fails, and resolving the issues with sides involved in the transaction.
Because of that settlements monitoring is one of the big challenges that Prime Broker has to complete.
Obstacles on the way
The business and development teams head to solve many obstacles to proceed with task:
Complex business logic, hard to understand for people not involved in trading
Lots of different stakeholders - departments responsible for reconciliation, reporting, brokers, and external providers
Criticality of the process
Various external sources of data with different processes and APIs
Various quality external sources
The requirement for easy extendability - introduction of new rules and new data sources
Time-critical task - processing time is one of the key aspects
To overcome these challenges, the team has worked with stakeholders to define separate domains and subdomains involved in the process and created a 'dictionary' for each of them.
Road to the success
working with stakeholders to define separate domains and subdomains involved in the process (input normalization, trade matching, reconciliation, notification, and reporting) and provide a 'dictionary' for each of them
use of domain-driven design for critical subsections of the system - matching and reconciliation
incremental implementation starting with support for the single biggest external data provider, followed by adding next data sources
developing system as microservice architecture - separate microservices for each external data provider and each domain
usage of different architecture styles for different parts of the system
Reduced the number of employees
Adopting to regulatory changes with no additional development
Reducing costs with on‑demand scaling
Reaping the benefits
Automation has reduced the number of employees working on the settlement process and shifted their focus from detecting fails to monitoring potential fails and contacting the sides of a transaction to resolve problems beforehand.
Clearly distinguished business rules in matching and reconciliation domains were exposed for power users so that they could adjust them to the ever-changing regulatory requirements with no need for additional development.
Modular microservice architecture has allowed easy addition of new external data providers (for example other settlement agencies which were not in initial scope), and on‑demand scaling of resources, therefore reducing need for costly IT infrastructure.
Additionally differentiating architectural styles between parts of the system allowed to use best one for each appliance - ‘pipes and filters’ for asynchronous data digesting and normalization, ‘hexagonal architecture’ for encapsulating complex business logic in matching and reconciliation microservices, and MVC with CQRS for ensuring high performance and responsibility of user frontend.
