How we designed Baton CORE™ to be extensible & interoperable with the power of distributed ledger technology (DLT)
I’m keen to share with you some key insights on the Baton CORE platform, especially on how we have engineered it to deliver maximum extensibility for our client banks.
Extensibility is central
Why is extensibility so important? Some tech solutions do not permit use in changed circumstances. An example might be a piece of software designed for a specific purpose, such as an accounting package, based on a fixed set of parameters. The design deals with current state systems and processes – ie. accounting rules applicable right now, but if you want to add another step to your workflow, it can’t be customised to do so, you’re dependent on the app’s developers making these changes – most probably in a future release.
At the other end of the extensibility scale are the major enterprise resource planning (ERP) packages, designed to be usable in a multiplicity of business environments and operations. Extensibility, in the form of customisation (as these types of solutions offer) is a key benefit as it means the technology can not only be used to achieve what it delivers out-of-the-box, but its functionality can also be extended.
When we think about commercial banking relationships and processes, they are of an order of magnitude greater in terms of complexity when compared with standard business accounting. Also, any customisation must also allow the solution to interoperate with other parts of the bank and be compatible with both the internal team’s and counterparty’s operations. Take for example a trade, once complete there are workflows that need to happen across both parties to the transaction and their trust boundaries. These inherent complexities have presented challenges in evolving systems and processes, necessary to deal with changing market practices and the introduction of new products which has meant delays in taking advantage of the digitisation made possible by the recent revolution in technology.
Ensuring extensibility, was at the forefront of our minds when we were building the Baton Core™ platform. We knew, if we could crack this problem with a framework built for interoperability, which was easily adaptable over time, anticipated change and was even open to changes (which we could not yet anticipate), we could deliver massive value for banks – in terms of trading efficiencies, enhanced visualisation and friction-free processes for both intra-bank flows and external trades.
Distributed ledger technology: Allowing each party to fully customise each proprietary process step
Our use of distributed ledger technology – DLT – provided the answer.
DLT allows each contracting bank to operate a node with party-defined visibility of data, so the node operates within the security realm of the bank and ensures data security by strictly limiting data access to the contracting parties of each trade (supported by our use of single tenant architecture). The parties agree to permissions on accessing data for those steps of the workflow which lie within the counterparty’s operations. Take for example, the 3-step process that must be completed once an FX trade has been confirmed – netting, agreement on netting and settlement – these steps are performed by both parties and involve workflows that are sometimes internal and at other times run between the parties.
“While the agreed steps between the banks are visible to both parties, those a bank choses to customise themselves (within their own node) are only visible to the customising party.”
At Baton, we appreciate the diversity of approaches to operations management and how process steps often differ between banks – so we designed Baton’s DLT to allow each party to fully customise each proprietary process step, their parameters and data inputs and outputs (as well as offering the ability to add new steps) to support and integrate both existing and new operations. We designed the solution to ensure that while the agreed steps between the banks are visible to both parties, those a bank choses to customise themselves (within their own node) are only visible to the customising party.
“Because Baton’s technology is fully interoperable it can seamlessly interact with the banks own systems such as core ledgers, payment gateways & messaging systems using secure access protocols, adapters & APIs – minimising disruption & risk.”
We put facilitating extensibility and enabling interoperability at the heart of our solution. We avoided the structure and language-bound difficulties of blockchain contracts which restrict customisation and chose DLT instead. Full customisation means banks can derive key benefits from Baton CORE immediately on implementation. Banks can bring Baton into their operations as part of an incremental evolution and because it’s fully interoperable it can seamlessly interact with the banks own systems such as core ledgers, payment gateways and messaging systems using secure access protocols, adapters and APIs – minimising disruption and risk.
Domain model approach
Our solution is informed by a domain model approach which looks at the lifecycle of the contract making it readily extendable across multiple workflows. We’ve avoided being hidebound by data modelling, which focuses on the structure of the data and doesn’t allow for customisation.
The domain model is more aligned to a bilateral legal agreement like an ISDA Master Agreement, where trades (e.g. FX trades, IRS trades etc) are executed between the banks under the umbrella of the ISDA Master Agreement. To settle these FX trades, each firm needs to follow a set of internal processes or steps and then a set of steps that require them to collaborate with their counterparty. The Baton workflow mimics this distributed real life flow, but brings in real-time visibility, permissioned shared data sets, auditability and non-repudiation, in addition to other benefits, to the process. Baton’s workflow typically starts when there is either a trade or a legally binding payment obligation. The platform then proceeds to manage the lifecycle of the event (the trade, meeting payment obligations etc) all the way to settlement between the counterparties.
“Clients can add custom steps at any point in the trade lifecycle & interact with their own internal systems for interoperability.”
Baton’s workflows start by identifying which process steps are customisable (or private) and which are visible (public) to the counterparty and require their agreement and collaboration.
It also lays out the steps that each party is supposed to do during the life cycle. Clients can add custom steps at any point in the trade lifecycle and interact with their own internal systems for interoperability.
Single source of truth: Resolves issues of data conflicts & questions of time precedence
The data for the trade does not live in a solitary location or with a given owner, as it does with traditional trading systems. Instead, a unified, permission-defined data set is accessible via the DLT to each party and at all times – the lineage of each trade being preserved by the DLT. This ‘single source of truth’ resolves issues of data conflicts and questions of time precedence. It provides cryptographic proof of both parties’ agreement to the details of the trade and the current status of execution via public and private keys.
“A unified, permission-defined data set is accessible via the DLT to each party & at all times – the lineage of each trade being preserved by the DLT.”
Our DLT solution provides the building blocks of extensibility and I hope that through this blog we’ve helped you understand why we feel it is such an important factor that requires detailed consideration when deploying new technologies. If you have any further questions about extensibility please do not hesitate to reach out and email [email protected].
This is the first in a series of blogs we will be publishing over coming weeks, exploring topics including how the Baton Core platform manages security and delivers resiliency, which we hope you find interesting.