Lossless Financial Systems
A Quick Story
Section titled “A Quick Story”Years ago I worked for an events startup. People (mostly companies) could come to the website and book events for their employees to attend. The economics were pretty easy to follow: the event providers got paid set rates per seat (or per event). We marked that up by 30%-50% to make sure it was profitable. The customer saw the marked up price and paid exactly that.
| Event Name | Cost | Customer Price | Profit |
|---|---|---|---|
| Event 1 | $100 | $150 | $50 |
| Event 2 | $250 | $325 | $75 |
There was a problem with this simple booking system. People came in, booked events when they wanted them, and then left. We were a startup though, and our investors didn’t care about consistent revenue, they only cared about recurring revenue. So how do you turn an at-will booking platform into a recurring revenue platform?
The idea was fairly simple: we’d sell contracts that gave customers credits each month. We’d price credits based on the average cost of an event, and then let customers redeem them at 1 credit per person per event. We imagined that our bookings would mostly look like this:
Customers loved it. The credit system was easier to understand. It didn’t require someone with a corporate credit card to book events. Sales had an exciting new ability to give customers a few more credits as an incentive to sign contracts.
Growth was good, sales were good, events were being booked. Everyone was happy!
… until the bills started rolling in.
The standard value of our credits was based on our average event cost. However, now that customers could trade 1 credit/person for any event, they began to overwhelmingly book our most expensive events. The reality of our bookings started to look a lot more like this:
As our cash reserves started to drop months later (we paid on net 45 or net 60) we finally realized that something was wrong. After a lot of frantic data analysis we finally figured out what was happening, but by then it was already too late.
Everyone made reasonable choices along the way, but how did things go so wrong? Why was it even possible to create a system that lost money so consistently?
This whole thing could have been avoided if we had built on top of a system designed to be financially sound from the ground up.
The meaning of lossless
Section titled “The meaning of lossless”We started String Theory to eliminate problems just like this. We started with a single ambitious premise: it should be impossible to build a financial system that loses money. We call these lossless systems.
Lossless systems are ones that proactively block financial losses from happening as their default behavior.
A lossless system needs to understand the actual flow of money through your company and to proactively block spending money when the unit economics would cause you to lose money.
- This needs to be true even if the money is moved through a bunch of intermediate accounts.
- It needs to be true even when different departments have conflicting business rules.
- It needs to be true even if the money is exchanged between currencies.
- It needs to be true even if the money is held for a long time.
It turns out that creating a system that can be considered lossless is really, really hard. So hard, in fact, that we’ve had to invent an entirely new method of ledgering to achieve it.
How does it work?
Section titled “How does it work?”Instead of using accounts like standard ledgering software, lossless systems need to track individual pieces of money as they move through your system. Then, they can block any spending that isn’t backed by available pieces of money in the system.
This can be done in a tightly controlled way, like ensuring that a credit can’t be used to book an event that costs more than the credit is worth. It can also be done at a much higher level like ensuring you have available money from any source to pay a vendor.
Going back to our startup example, when a customer tried to book an event with a credit that wasn’t worth enough to cover the cost, a lossless system would have blocked the transaction by default.
Chances are we don’t actually want the customer to get an error when they try to book this event, that would feel pretty bad. Now that we know a loss is about to occur though, we have everything we need to make an intentional business decision about whether we should hide the listing all together, subsidize the loss, or let the customer get an error. No matter what we choose, we’re in full control of the situation.
Isn’t this a lot of work for me?
Section titled “Isn’t this a lot of work for me?”If you want to try to build a lossless system yourself… oh yeah. That’s going to be a huge amount of work.
Using String Theory it’s easy to get started with all but the most complex of financial flows. Even in the complicated cases we’ve got a suite of tools that allow you to build lossless products that still have the flexibility you need. Features like multiple currencies, multiple exchanges, incentives, charge-backs, refunds (and much more) give you everything you need to handle even the toughest business rules.
String Theory is designed so that the easiest thing to do is build a lossless system. The more financially risky a behavior is the harder it is to do.
If you are trying to add String Theory to a currently insolvent system it is going to take longer, but the process of integrating String Theory will point out exactly where those losses are coming from and give you the tools to start making intentional decisions about how to fix them.
Doesn’t my account system already do this?
Section titled “Doesn’t my account system already do this?”The short answer is no. For the long answer, you can read our blog on the Zero Sum Fallacy.
Accounting systems lose auditability rapidly when money is pooled for any reason, and loss can easily be hidden inside of positive balances in the system. This makes it extremely hard to detect loss consistently, or to pinpoint the cause of loss even if it can be detected.
What if I want to lose money?
Section titled “What if I want to lose money?”Alright, I phrased this in an intentionally provocative way, but it’s actually a really common thing for businesses to want to do. We intentionally risk money all the time for marketing campaigns, to promote new products, or just to make a client happy in the hope of getting better business in the future.
String Theory still allows you to do these things, but requires that the loss is carefully managed. You can learn more about how to do that in our blog on Risking Fearlessly.
Caveats
Section titled “Caveats”If you are suspicious of our claims of a lossless system, you’re not totally wrong. Even though String Theory itself is lossless, it’s still possible to lose money while using it since we can’t control what happens outside of the system. Here is a more nuanced statement on what it means to be lossless, and some of the ways it’s still possible to lose money when using String Theory.
String Theory ensures:
- Your systems can’t spend money that you don’t have.
- Any loss you would create must be explicitly allowed by an intentional business decision.
- All acceptable loss must be explicitly budgeted.
What String Theory can’t proactively prevent:
- Losses due to 3rd party actions.
- Losses due to giving String Theory incorrect data.
- Losses due to not providing data that String Theory needs to do its job.
- Losses due to not honoring String Theory responses.
Payments and billing providers can do some really weird things in edge cases. Although String Theory can’t prevent them from doing that, it will detect the behavior and let you know the moment it happens.
Ready to make your systems strictly profitable?
Section titled “Ready to make your systems strictly profitable?”Talk to our sales team to get a free demo or consultation about your financial systems.