Formance – The Color of Money: Towards a New Data Model for Fintech, Part II(formance.com)
formance.com
Formance – The Color of Money: Towards a New Data Model for Fintech, Part II
https://www.formance.com/blog/engineering/color-of-money
3 comments
I'm not sure that's true as double entry bookkeeping breaks down with multiparty transactions. Any solutions are extensions to plain double entry bookkeeping, in which case why not use a proper ontology like REA which actually reflects real things that exist instead of fictitious entities like "accounts" and "ledgers" that you have to understand through the lens of an accounting model?
Formance claims:
"It’s customary in classical accounting to treat money as fungible, because classical accounting is expressly for the purposes of evaluating the overall situation of a business—assessing its financial health, detecting irregularities and fraud, and providing tools for auditing and verifying any claims about the overall situation by looking at whether assets and liabilities are balanced."
The problem here is that fintechs seem to want to run basic accounting software instead of banking software. These problems in banking were solved a _long_ time ago; banking wasn't the first application of computers, but they were certainly one of the first (with Bank of America having a purpose-built computer in 1959 for cheque clearing, and Barclays also in 1959 using a computer for more general purpose banking).
Banks already figured out how to solve the problems fintechs seem to be puzzled by now, and did it with first entirely paper based workflows and then later punchcard-assisted workflows for tabulation, such as "how much money does customer X have in his account?" This included things like a "local cache" of such data (for a customer with passbook savings) and dealing with all manner of fraud, and detecting that fraud without the assistance of computers.
Formance's idea here is not particularly innovative or new, and also reflects a rather common mistake when designing ledgers. A unique combination of "attribute" (which these people are calling "colours") is simply another account. This results in a somewhat undesirable proliferation of accounts.
If you use double-entry accounting and make sure your accounts are balanced and your balacing accounts are zero at the end of the day, your statements are finalised and printed and sent to your accountholders at the end of the month, your executive management refers reports of such balances each quarter, and your books independently audited each year, you will have the same results that have come from conventional banking from the days of the ancient Sumerians to the present day.
Or, y'know, fintechs could just keep inventing "new" banking models, which I guess they need to do to pretend they're doing anything more sophisticated than finding a way to juice up debit-card transaction activity at tiny banks that are allowed to charge more than big banks.
"It’s customary in classical accounting to treat money as fungible, because classical accounting is expressly for the purposes of evaluating the overall situation of a business—assessing its financial health, detecting irregularities and fraud, and providing tools for auditing and verifying any claims about the overall situation by looking at whether assets and liabilities are balanced."
The problem here is that fintechs seem to want to run basic accounting software instead of banking software. These problems in banking were solved a _long_ time ago; banking wasn't the first application of computers, but they were certainly one of the first (with Bank of America having a purpose-built computer in 1959 for cheque clearing, and Barclays also in 1959 using a computer for more general purpose banking).
Banks already figured out how to solve the problems fintechs seem to be puzzled by now, and did it with first entirely paper based workflows and then later punchcard-assisted workflows for tabulation, such as "how much money does customer X have in his account?" This included things like a "local cache" of such data (for a customer with passbook savings) and dealing with all manner of fraud, and detecting that fraud without the assistance of computers.
Formance's idea here is not particularly innovative or new, and also reflects a rather common mistake when designing ledgers. A unique combination of "attribute" (which these people are calling "colours") is simply another account. This results in a somewhat undesirable proliferation of accounts.
If you use double-entry accounting and make sure your accounts are balanced and your balacing accounts are zero at the end of the day, your statements are finalised and printed and sent to your accountholders at the end of the month, your executive management refers reports of such balances each quarter, and your books independently audited each year, you will have the same results that have come from conventional banking from the days of the ancient Sumerians to the present day.
Or, y'know, fintechs could just keep inventing "new" banking models, which I guess they need to do to pretend they're doing anything more sophisticated than finding a way to juice up debit-card transaction activity at tiny banks that are allowed to charge more than big banks.
(Disclaimer: I’m the author, nice to see your take here and pleasantly surprised to see my post here as well!)
You can surely use accounts with fine grained attributes (e.g. to describe the soon to be received but not yet available money or customer 1234, naming it users:1234:pending). You can even add more data to this account on a metadata level (e.g. finer grained accounting classification).
The problem with an account-only approach is that a monetary value represented in it is only temporarily represented here, and if there’s a specific set of attribute relative to that value, you’ll be somewhat forced to overly complicate your structure of accounts to persist theses values throughout the ledger.
Banks are not fintech and hence face different issues so let’s take an example anchored in that context. Imagine you’re holding $100 for user 1234, spread across two FBO accounts at two different banks. You might be interested in persisting the nature and location of these funds throughout the ledger. So instead of having an account structure such as users:1234:main:jpmc, users:1234:main:fargo and so on, you could simplify your ledger structure by having a single users:1234:main holding something like:
But that’s just an example, the idea is to explore the concept of semi-fungibility and how it can improve some of the challenges fintech face (in their journey of being not bank).
You can surely use accounts with fine grained attributes (e.g. to describe the soon to be received but not yet available money or customer 1234, naming it users:1234:pending). You can even add more data to this account on a metadata level (e.g. finer grained accounting classification).
The problem with an account-only approach is that a monetary value represented in it is only temporarily represented here, and if there’s a specific set of attribute relative to that value, you’ll be somewhat forced to overly complicate your structure of accounts to persist theses values throughout the ledger.
Banks are not fintech and hence face different issues so let’s take an example anchored in that context. Imagine you’re holding $100 for user 1234, spread across two FBO accounts at two different banks. You might be interested in persisting the nature and location of these funds throughout the ledger. So instead of having an account structure such as users:1234:main:jpmc, users:1234:main:fargo and so on, you could simplify your ledger structure by having a single users:1234:main holding something like:
[USD/2 100 (bank: jpmc)]
[USD/2 100 (bank: fargo)]
But that’s just an example, the idea is to explore the concept of semi-fungibility and how it can improve some of the challenges fintech face (in their journey of being not bank).
For technical discussion:
This is easy to represent with double ledger accounting.
We have a customer ledger which in normal banking balances as a bank liability against the bank’s assets held in Treasurys or cash or whatever.
You seem to want a report of where you are allocating the customer funds. This isn’t possible in any sane way without having individualised accounts, any more than it is sane for me to ask my bank “Ok, I have $1,000 in checking, how much is held in short term assets of the bank, Treasurys, long term assets like mortgages held by the bank”? It’s not a reasonable question since they’re fungible.
If you truly want to hold FBO accounts at your banker’s bank then you do indeed create a hierarchy like this:
AwesomeFinTech:Assets:BoringBanks:JPMC:Clients:Jim AwesomeFinTech:Assets:BoringBanks:BoA:Clients:Jim AwesomeFinTech:Liabilities:Clients:Jim AwesomeFinTech:Liabilities:Clients:Jim:JPMC AwesomeFinTech:Liabilities:Clients:Jim:BoA
When you move funds into the FBO account (which is just the Assets:JPMC account), balance the transaction against both the liabilities and assets.
You can a report on the liabilities:client and see where the funds are.
If you want to see all your assets at JPMC for Clients, you can see that.
If your fintech fails and you need reports of all the funds at JPMC… easy, go dump the balances of all the JPMC:Clients accounts.
This is easy to represent with double ledger accounting.
We have a customer ledger which in normal banking balances as a bank liability against the bank’s assets held in Treasurys or cash or whatever.
You seem to want a report of where you are allocating the customer funds. This isn’t possible in any sane way without having individualised accounts, any more than it is sane for me to ask my bank “Ok, I have $1,000 in checking, how much is held in short term assets of the bank, Treasurys, long term assets like mortgages held by the bank”? It’s not a reasonable question since they’re fungible.
If you truly want to hold FBO accounts at your banker’s bank then you do indeed create a hierarchy like this:
AwesomeFinTech:Assets:BoringBanks:JPMC:Clients:Jim AwesomeFinTech:Assets:BoringBanks:BoA:Clients:Jim AwesomeFinTech:Liabilities:Clients:Jim AwesomeFinTech:Liabilities:Clients:Jim:JPMC AwesomeFinTech:Liabilities:Clients:Jim:BoA
When you move funds into the FBO account (which is just the Assets:JPMC account), balance the transaction against both the liabilities and assets.
You can a report on the liabilities:client and see where the funds are.
If you want to see all your assets at JPMC for Clients, you can see that.
If your fintech fails and you need reports of all the funds at JPMC… easy, go dump the balances of all the JPMC:Clients accounts.
We may have a philosophical disagreement since I think fintechs definitely are banks, or at least pretend to be banks. What you call a “bank” is what (for example) my credit union or my local town’s small bank calls their “banker’s bank”. They do indeed store their funds, generally speaking, at their banker’s bank; I know for a fact one of them primarily uses Chase.
Their banking software keeps reliable ledgers of balances and posts changes nightly to their banker’s bank.
They prepare for data loss with off site backups. This stuff has been done in banking since at least the 1970s.
Anything being out of balance is a major emergency. If it’s a software problem, they would immediately demand action from the software vendor, who will drop whatever else they are doing by and fix the problem.
The “journey of being not a bank” is puzzling since someone who doesn’t want to be a bank really isn’t someone who should be holding client funds.
Their banking software keeps reliable ledgers of balances and posts changes nightly to their banker’s bank.
They prepare for data loss with off site backups. This stuff has been done in banking since at least the 1970s.
Anything being out of balance is a major emergency. If it’s a software problem, they would immediately demand action from the software vendor, who will drop whatever else they are doing by and fix the problem.
The “journey of being not a bank” is puzzling since someone who doesn’t want to be a bank really isn’t someone who should be holding client funds.
[deleted]
The color annotation system here is interesting but could be easily modeled with just accounts. In fact in some implementations that I've personally built, that's exactly what we did. Accounts were bags of attributes, including currency and color.
Not to say the system as described is deficient in any way, just that it isn't any different than a plain ledger except as a notation. I'll be interested to see the follow up articles about "transmuting".