Under the bonnet of Origin’s Equity-linked Structured Note offering
This week on the blog, Origin’s Co-founder and CTO Robert Taylor talks about our exciting structured notes extension to our Documentation product.
We recently announced that MUFG’s Structured Solutions business has collaborated with Origin to automate all documentation for their Equity-linked Structured Notes business.
This has been a hugely enjoyable project to work on as an engineer, and we honestly couldn't have wished for a more friendly, supportive and forward-thinking counterparty in MUFG.
As a quick summary, MUFG uses Origin Documentation to generate all documentation for their equity-linked notes business. Trades are sent down electronically via API to achieve straight-through-processing (STP) and we generate a wide range of documents covering termsheets, final terms, Murex booking files and various csv reports.
Extensibility & Unknown unknowns
One of the core principles when it comes to building software is extensibility, the ability to seamlessly extend and build upon previous work.
Naturally you try to plan ahead and build with future functionality in mind, but what makes building software so challenging is the unknown unknowns. You simply can't predict all the weird and wonderful requirements clients will have in the future.
“There are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns – the ones we don't know we don't know.”
– Donald Rumsfeld
Unfortunately, it's usually only when you need to add new functionality that extensibility is really tested, and you realise that what you'd previously built isn't compatible. If that’s the case, you either end up “fudging” it (which in turn often causes technical debt, a topic I'll write again on soon), or you do a re-build, which can be incredibly costly.
Real-life benefits of cloud technology
What's great is that the solution being used by MUFG uses the exact same functionality that our clients use to do Vanilla issuances every week. This is exactly where you see real-life benefits of using cloud technology, since improvements to the code base are immediately felt by all clients as they use the same platform rather than separate deployments, which can marry you to long release cycles.
The key difference is that whilst for vanilla issuances, the user creates the trade on Origin through the browser, here trades are created electronically via API.
We had already opened up our Airbrush API for consuming trade data, which a number of clients are already using to consume trade data. For this solution, we created a new API allowing customers to create trades via API, enabling straight-through-processing (STP).
Everything else is exactly the same. The trades appear in the blotter as usual, users get to use all of our collaboration functionality out of the box (comments, suggestions, reviews, approvals), and because we've built the various components in a modular way, we can easily tailor the “flow” to exactly match users’ needs.
For example, having 1 documentation stage, followed by a review/approval process, an instant ISIN stage, a Docusign e-signing stage and finally a submission to the IPA of the signed final terms and structured transaction data.
Logic layer
The initial structured data being sent down Origin via API contains a non-exhaustive core set of data fields, which is then augmented by our logic layer to create 100s of further data points.
This logic layer allows us to preset default values based on arbitrary business logic, as well as perform all kinds of calculations and data manipulations.
Our approach to validation
Given the highly complex nature of equity-linked notes (often involving digital coupons, knock-ins, knock-outs,lengthy annexes, dynamic data tables etc), combined with the fact that you might be doing 50+ different trades on any given day, the output validation stage of the build process is incredibly important.
You need the outputs to be perfect, or you'll rapidly be drowning in manual interventions. With MUFG we defined a validation set of trades that span the various trade types and edge cases. This data set was used to sign-off our templates, as well as form the basis for our automated test suite. These tests run automatically every time one of our engineers pushes code into our repository, ensuring that the structured data we generate for each trade is always valid.
We've invested a lot of time building out our document templating technology, ensuring that we can handle the challenges brought on by such complex documentation requirements. Our work has replaced dozens of separate trade templates, ensuring there is one golden source of truth per document type. We’ve also developed support for a wide range of document types, including csv reports and Murex booking files.
The importance of robustness
Last but not least, I wanted to discuss robustness.
There's no point building all this wonderful technology if it's not reliable. For this type of functionality you need to ensure that your services are always available as trades could be sent down the pipe at any time.
At Origin we're big proponents of self-healing infrastructure, whereby if a part of your infrastructure goes down then it should automatically heal itself and come back up.
In light of this project, we set up an automated testing service which simulates a real trade every 20 minutes against our production environment, which triggers a myriad of alerts if it encounters any issues. Needless to say how seriously we take this topic.
Finally, I want to use this blog post to thank our unsung heroes who work tirelessly behind the scenes. This goes out to all of our product managers, engineers, designers and testers. Without their hard work, none of this would have been possible.
