As engineers, we want to automate everything. It’s one of our core values at Addepar. There’s nothing more satisfying than seeing a huge collection of data neatly line up exactly the way you want it to, with every edge case taken care of and every peculiarity accounted for. The tricky thing, though, is that we’re […]
As engineers, we want to automate everything. It’s one of our core values at Addepar. There’s nothing more satisfying than seeing a huge collection of data neatly line up exactly the way you want it to, with every edge case taken care of and every peculiarity accounted for. The tricky thing, though, is that we’re solving the problems of the financial world — a system that is inherently made up of and built by people. It’s laden with incentives for creativity, and we see those sparks of innovation in new products and transactions. This ingenuity is what makes finance special. But the state of perpetual flux also makes full automation impossible.
At Addepar, we’ve decided to embrace the mindset of the financial world. We want to allow people to flex their cognitive and deductive skills, while still using automation as a guiding mechanism. We want to stay flexible and yet harness the power of computers, just like the people-centered system we’re trying to model. This approach lets us stay up-to-date. In this blog post, I’m going to dive into one of the most complex and variable financial transactions we encounter at Addepar — corporate actions — as well as some of the lessons we’ve learned about incorporating human insight into our technology.
Corporate reorganizations occur often. They can be some of the most high-profile and financially impactful things you hear about: Microsoft purchasing LinkedIn, Amazon purchasing Whole Foods. While certain variations are quite common, these transactions can, and do, get arbitrarily complex. There’s a great deal of variance from one to another and it’s no mystery why — the flexibility on what can be done is very high. Of course, you have certain legal constraints (based on the existing assets/liabilities of the company), operational constraints (the more complicated the transaction, the more costly), and then the hurdle of getting board approval. Beyond that, though, it’s pretty much an open field. We know we can’t predict every possibility; the only guarantee is that we’re going to encounter something we haven’t seen before. Let’s go back in time a little bit and examine a corporate action that was, at the time, uncharted territory.
On April 15th, 2016, Liberty Media Corporation went through a reorganization that our system wasn’t really equipped to handle. Existing common stock was split up into three new distinct securities, at various ratios. The press release goes into the fine details of the transaction, but the basic flow is outlined below. This is an excellent example of a company doing whatever it wants to and, correspondingly, why it is so hard to automatically process these transactions.
The thing to take note of here is that this transaction was represented in an ever so slightly different way by each of our hundred plus integration points. Naturally, being engineers, we went right to work on automating all of it. The result was an incredibly long and arduous day. A quick search reveals that we have dozens of specific methods or variable names relating to this corporate action. We wrote a lot of code and, frankly, I’m skeptical that any of those code paths have been hit since that day. It was an impactful event for us, though, because it caused us to rethink the way we approach these problems altogether. Analysts were able to look at these files and know in seconds how different pieces tied together. Engineers, however, found it difficult to automate all of their deductions just by using the information in the files.
We sat down and thought about the problem. We wanted to learn from this experience and apply those findings to the way we approached corporate actions in the future. What were the parts we could always automate? At what point would it make sense to involve a human to provide guidance? The goal was to find a sweet spot where we could stay fully automated except in those cases where potential ambiguity lay.
Let’s take a quick step back here and look at the components of a typical transaction.
In every one of the hundreds of thousands of transactions Addepar processes every day, there are two main things we aim to get right: the accounting portion and the performance, or grouping, portion. In order to do that, we need to formulate all possible interpretations of our incoming data. This means taking stock of both the information we’re getting and the information we’re not. We’ll talk later about which parts can be easily automated and which parts can’t. First, let’s think through an example to demonstrate what these two components mean in the financial world.
You are walking down the street with two whole dollars in your pocket. A trinket from a street merchant catches your eye and you purchase it for one dollar. You now have one dollar and one trinket. The accounting portion here of this transaction is twofold: the gain of a trinket and the loss of a dollar. The grouping portion is the part that ties these two actions together for you. The dollar didn’t just disappear and the trinket didn’t just materialize — these two things are inextricably linked to each other.
This is one of many problems we’re faced with every single day in the world of performance reporting. These two things are the inputs to many of our calculations and thus getting them right is critical. If we don’t, well… let’s see what happens if we don’t group them.
These are the performance charts for cash and for the trinket. We can see that the performance for cash isn’t great. It looks like, in a single instant, we lost half of the value of our cash for no apparent reason. It was worth $2, but is now worth $1. At the same time, a trinket appeared out of nowhere, causing an infinite return. Something that used to be worth $0 is now worth $1!
What should these charts actually look like?
The value of cash or of a trinket doesn’t change just because it is exchanged for something and the performance chart should reflect that. Grouping this exchange isn’t too hard — trinket comes in, cash goes out. Every purchase follows this general pattern. With corporate actions, though, there is no pattern and that’s what makes it such an interesting problem.
Let’s say we get a file with the following data.
Should this be interpreted as the diagram on the left or the one on the right? We know there are corporate actions happening, but the way each is grouped isn’t clear from the file.
Our system is excellent at capturing unit inflow or outflow on individual securities — we rarely get this accounting portion wrong. The situation only becomes more delicate when we start trying to deduce how these flows should be paired. Most financial transactions are well-defined and piecing them together, while a challenging problem, is still something very achievable. For the less defined ones, like corporate actions, it can be very easy to fall into an over-optimization rabbit hole. We’re dealing with a transaction that has an unknown amount of pieces, with each going in an unknown direction at unknown ratios.
We decided that, instead of trying to force a structure to be defined and applied before it was necessary, these intricate events would instead just be processed as uncoupled basic transactions that make up the event. These transactions capture all of the individual information and unit deltas on each security, doing as much of the work as possible. This is the accounting portion mentioned earlier and it is something that is always automatable.
The only pieces absent now are grouping and direction. We’ve isolated and tackled everything with automation except for these components, which a person can resolve quickly and accurately. We obtain this structure by asking the user two questions.
Over time, as patterns emerge in these groupings, we acknowledge them, learn from them and introduce new automation, reducing the amount of human intervention necessary. This eventually leaves us with a system where supervision is only necessary in special snowflake scenarios.
My favorite analogy for this is a railroad. All of the trains are built and zooming along — we just need someone to know which levers to pull so that they all arrive at the correct destination. As more trips take place and our sample size grows, more automatic controls get incorporated.
We’re continually learning lessons at Addepar. With a massive and ever-changing financial world, we have to make sure we are ready to adapt as it evolves around us. Keeping our data models flexible is one way we are enabling ourselves to stay attuned to the financial world. Accepting the fact that not every problem is best solved by only using technology is another philosophy that has proven to be tremendously rewarding. As an engineer at Addepar, a place that defines itself by its tech, this is personally humbling. If we want to tackle and solve the problems that matter, we need to stay as nimble as the ecosystem we’re operating in. Sometimes, this will mean going down unfamiliar and unintuitive paths.
Despite continuously being hard at work on improving our pipeline, we’re always looking for new ideas. Drop us a note below!