While front-office technology has enabled trading in nanoseconds, post-trade processing remains manually intensive, opaque, restrictive and slow.  Interoperable SaaS platforms can provide efficient, future-proof solutions allowing firms to achieve friction-free processing implemented with minimal disruption. 
Post-trade processing: time to refresh?

Post-trade Operations Managers are often concerned that technology upgrades will prove disruptive, risky and expensive. The inherent complexity of under-invested, ageing infrastructures, has resulted in inflexible environments plagued with inefficiencies. Furthermore, with a wide range of custom approaches to managing liquidity, credit, payments and risk in individual institutions, retaining these proprietary core components, whilst the wider infrastructure is upgraded, is essential.

Many firms avoid prioritising an upgrade because of the perceived intractability. Fortunately, the emergence of new interoperable Cloud-based SaaS (software as a service) solutions means the benefits of upgrading can now be achieved with rapid modular implementation, often fully customisable, these solutions can then interact smoothly with existing systems so core components can be retained and form part of a fully connected infrastructure. Forward-looking firms now see these solutions as a realistic opportunity to create the architecture required for the bank of 2030.

Upgrading new technology: 3 key integration considerations

Having differentiated core proprietary components from those migratable to the Cloud, planners can look at how they can incorporate these new SaaS solutions to ensure they are  interoperable with the bank’s existing systems and processes. As technologists and operations managers commence the upgrade process, the three key areas it’s important to pay careful attention to are: 

  1. Transport – the types of secure messaging between components 
  2. Interoperability the compatibility of data formats via robust protocols using well researched and documented enterprise integration design patterns
  3. And operational resilience – engineering to resist faults and external attacks 
1) Transport: Technology leaders should review the types of message formats they’ll be using to connect to SaaS solutions 

SaaS and core services generally ‘speak’ to each other via a combination of three secure message types:

  1. Message queues (MQs) and pipes: industry operators have coalesced around products such as MQs often processing 10,000s of trades per second
  2. REST and API calls: via white-listed sets of IPs, certificates are pre-exchanged to ensure speaking to certificated endpoints, with all data encrypted 
  3. Secure FTP: files sent by secure FTP (file transport protocol)

This market-tested connectivity plays a key role in making SaaS-based systems both extensible and resilient.

In planning implementation on MQs and pipes, technology teams should consider their requirements for architecture, storage and performance, resourcing for data sets, page sets, coupling, logging and backup facilities. Deploying the strongest encryption technology is essential for your Transport Layer Security (TLS) and SFTP.

2) Interoperability: Think about the types of data formats you’ll be using – SaaS systems can transmit both standard and custom formats to core systems 

Standardisation is the starting point for delivering interoperability with established protocols existing for widely-used file formats like XML, JSON and CSV. However, standardisation is far from universal, thus implementing customisable connections which speak to multiple systems is key.

For example, a banks’ operations must be able to interact effectively with the systems of a given counterparty to monitor asset delivery or access components which govern asset movements. Baton System’s Core-FX platform achieves this for example by interacting in real time with the banks’ existing systems and processes to capture the key information needed for a transaction to be able to progress onto the next step in the workflow. 

Industry-standard SaaS systems are designed with a high degree of tolerance when dealing with daily operational concerns such as rapid validation of data at scale and idempotency – these elements are needed to manage events arriving out of sequence.

3) Operational resilience: Start planning to ensure continuity pre and post adoption of  your SaaS-based system 

Leading interoperable SaaS systems are engineered with the most robust defences to internal faults and external attacks. To ensure these protections are optimised in a live production environment, it’s important to have implemented both operational and governance models with comprehensive SLAs, KPIs and other reporting and monitoring in place.

Initial testing: can be conducted in end-to-end test environments, but it’s also possible to roll out a SaaS system incrementally using live environments by gradually extending the functionality being tested.

Territory variation: Global trading means an operation will contain design elements that vary subject to regulations in different territories. So it’s important to build in these variations from the design phase onwards and subject each to resilience testing. 

Business Continuity Plans: These critical plans should clearly detail roles and responsibilities, and document scenarios with recommended actions. These plans should be socialised with all stakeholders using walkthroughs and annual simulation tests.

BAU: When you’re up and running, resilience is achieved via monitoring, reporting, alerts, case management tools and by maintaining an effective service portal with responsibilities clearly defined in SLAs and shared proactively among all relevant stakeholders in internal and clients’ teams.

Monitoring and reporting should have practical consequences – triggering health checks, for instance, if data endpoint monitoring shows an error. Building in daily use of dashboards can be a powerful tool here. Teams can also use runbooks to document the steps performed at each level, which are then measured against KPIs for thresholds such as CPU, memory and network etc.

Security: keeping a focus on infosec from system design through to BAU

Market participants appreciate that security attacks are constantly growing in sophistication. Security is a paramount concern and should be considered from the first steps of design to BAU.

Planners should consider deploying market-proven technology solutions in their SaaS upgrades with high level security requirements to include matters such as: least privilege access, the documentation of passwords, vulnerability testing and penetration testing – both internal and external. 

To ensure that every step is taken to optimise security consider scheduling live simulated attacks from third party partners. These can be invaluable in training teams and clients in readiness.

Blog post first published on Finextra on March 18th here