By Matthew Van Buskirk
What do shipping containers and your compliance technology stack have in common? Unfortunately, not much at the moment. One is an innovation that formed the core of a vast, interconnected system that enables global commerce to flow freely, cheaply and quickly. The other is probably a rat’s nest of legacy systems, COBOL databases and spreadsheets held together by chewing gum and frustration.
In his book titled The Box: How the Shipping Container Made the World Smaller and the Economy Bigger, Marc Levinson describes how shipping worked before the advent of containers. Shipping was extremely labor-intensive, with approximately 75 percent of the cost of shipping tied to activity in docks. Imagine a ship full of goods arriving at a port. People were required to unload the cargo, sort it by type and destination and repack it into trucks for the next leg. This process was also slow, with ships generally stuck in port for more than a week. The overall cost was significant enough that it meant that global trade for lower-margin goods was rarely profitable.
Contrast that with the world today, where a container can be shipped from a factory in Asia to its final destination on the east coast of the U.S. with multiple transfer points in between in a bit more than two weeks for less than $10,000. The idea that led to this transformation was the realization that it would be a lot simpler to just put the trucks on ships. It didn’t take long for them to remove the wheels from the truck to create the shipping container.
The idea alone was not enough. Levinson notes that containers were all the shipping industry could talk about in the 1950s, but there were no agreed-upon standards, leading to a proliferation of different models. It wasn’t until the various industry bodies involved agreed upon a standard size and an interchangeable locking system for the containers that the world we see today was created.
So why draw the comparison?
Compliance teams today mostly fall into one of two buckets that strongly resemble the shipping industry stages of the past: pre-container and pre-standards.
Pre-container: These are the financial institutions that are stuck with legacy technology, old core systems, fragmented databases and maybe even filing cabinets full of paper. They are heavily dependent on people to perform the work and much of the work that they are doing is repetitive and does not fully leverage their expertise. The only tool they have for handling changes in volume of work is adjusting headcount.
Pre-standards: These institutions have invested in more modern technology over the past several years. They may have moved to the cloud. They have replaced what old systems they can and have tried to apply robotics to those that they can’t. However, they face an entirely new challenge caused by a proliferation of systems that don’t talk to each other. They may have different case management tools for each queue that they manage. They are much better off than their “pre-container”” peers in terms of efficiency and effectiveness, but they still have to rely heavily on their people to bridge all of the different tools. There is still a lot of room for improvement.
The truth is that today, the only financial institutions that are not stuck in one of these two stages are the most sophisticated (and large) fintech companies that have dedicated engineering teams embedded in their compliance functions. These engineers spend their time combining homegrown technology with solutions from multiple vendors to build a compliance technology stack that is tailored specifically for their risk profile and needs.
Most compliance officers can only dream of having a team of engineers dedicated to their needs full time. That doesn’t mean that they can’t learn from what those fintech firms are doing to take their programs to the next level. The key is to take a modular design approach to your program. You need your own version of the standards and the interchangeable locking systems allowed containers to revolutionize shipping.
What does that mean in practice? Essentially, it is a small shift in how you think about your vendors and a small investment in compliance engineering. Many vendors present themselves as comprehensive solutions for all of your needs. This sounds great in theory but the compliance space is so complex that the reality is these vendors are often one-size-fits-none.
Instead of looking for vendors that check as many boxes as possible, you should split up your program into functional components and look for the vendors that are best for each piece and plug them into a modular framework that you build yourself. Using transaction monitoring as an example, where you would have previously relied on the vendor to decide whether to approve or deny a transaction, you design your internal system to query the vendor to ask it for its recommendation.
The difference seems subtle, but it has significant implications. First, it means that you are no longer constrained by the vendor’s design limitations. If its rules engine produces repeated false positives or negatives, you now have the data sciences infrastructure in place to override their recommendation.
Second, it means that you can plug in other vendors to get additional context and compensate for weaknesses. Finally, it gives you the option of yanking out a vendor and replacing it (or even building the capacity in house) if you don’t like its performance.
The ability to do this does require that you have access to engineers but it doesn’t require that you maintain the kinds of teams you see at the large fintechs. All you really need is the ability to avoid relying on the vendors to install themselves. If you have access to your own implementation engineer, the dynamic changes completely. You can put the pieces together however you want.
Matthew Van Buskirk is co-CEO of Hummingbird Regtech.
