Skip to content
← Writing

Article

There Is Always a Middle Account

healthcare · actual state · payments · systems

I spent months designing a system around "person to person" before I drew how a dollar actually moves. Every transfer is two instructions with an account in between.

Nobody has ever sent money directly to another person.

That sounds like a technicality. It is not. There is no instruction anywhere in the American payment system that says take five hundred dollars from Ann and give it to Ben. The message format cannot express it. Every rail has the same shape: one party is named as the originator, one party is named as the receiver, and the transfer settles against the originator’s account. One instruction, one direction, two parties.

So a payment from Ann to Ben is never one instruction. It is two. Something pulls from Ann. Something pushes to Ben. In between, the money is in an account.

That account always exists.

What I thought

I co-founded Cowboy Christian, a company where members pay each other’s medical bills. Not insurance. Not a pool that an operator sits on. People covering people, at the moment somebody needs covering.

The design rested on a sentence I had written and reread a hundred times: money moves directly, member to member. I meant it in the plain-English sense, the sense in which I hand you a twenty. I never went past the plain-English sense, because it did not occur to me that there was anything past it. It read like a description of a mechanism. It was a statement of intent wearing a description’s clothes.

What drawing it did

A few weeks ago I sat down to draw the money flow. Not to design anything. To draw what I already believed, box by arrow by box, so I could put it on a screen and point at it.

I expected three boxes. Member, rail, member.

The first thing that went wrong was that I could not label the middle arrow. I knew which network the money would travel on, and I went to check what the actual instruction looked like, expecting to find a field I had not memorized yet. What I found instead was that the network’s entry format names exactly one originator and one receiver, and settles the other side against the originator’s own account. There is no third slot. There is no version of the message that moves value between two consumers without one of them, or somebody else, being the account of record.

So the middle of my diagram was not an arrow. It was a box. And a box has an owner.

Expected payment path versus the actual one Two rows. The top row is what most people picture: Ann, a rail, and Ben, with the middle drawn as an arrow. The bottom row is what the payment message formats allow: an instruction pulling from Ann, an account in the middle, and a second instruction pushing to Ben. The middle is a box, and a box has an owner. What everyone pictures Ann Ben the rail What the message formats allow Ann Ben An account somebody owns this pull from Ann push to Ben two instructions, never one

This is not a quirk of one network. Wires have it. The instant rails have it. Cards have it worse, because a card transaction is an authorization now and a settlement later and a reversal window after that, with a processor holding the position the whole time. Even the friendliest case, where both people bank at the same institution, is not an exception. There, the transfer is a ledger entry: the bank lowers one number and raises another. Nothing moved. One party decided both numbers. That party is the handler, and it is a handler even when it never touches a wire.

The layman’s version of a payment is person to person. The financial version is person to a middle account to person, or at minimum one institution changing two numbers it controls. I had been designing against the layman’s version for months.

The account is also a duration

The second thing the drawing surfaced was that the middle account is not only a place. It is a length of time.

The distance between arrived and final A timeline in days from the moment a payment arrives. A short bar shows returns for insufficient funds coming back within days. A long, open-ended bar shows an unauthorized consumer dispute running about sixty days from the statement date. Money is not final until both windows close, and the middle account holds it for that entire span. The money has arrived. It is not yours. “arrived” final Insufficient funds back within days Unauthorized dispute about 60 days from the statement 0 15 30 45 60 75 90 days somebody is holding it for all of this

The cheap rails are the reversible ones. A consumer can dispute a debit as unauthorized well after it lands, and the window runs about sixty days from the statement. Returns for insufficient funds come back within days. Money that has “arrived” is not final for weeks. Which means the middle account is not a millisecond of transit that you can wave off in a diagram. It is a place where somebody else’s money sits, exposed, while the clock runs. Every failure path in a payments system is downstream of that clock.

You cannot design the failure paths until you know who is standing in the middle holding the clock.

The only question left

Once the middle box is on the page, the design question changes completely. It is no longer how do we move money directly. That question has no answers. It is:

Whose account is it, and what legal wrapper is around it?

There are only a few answers, and they are all publicly known shapes. The operator’s own account, which is simplest to build and means the operator is holding other people’s money. A licensed partner’s account, held for the benefit of the end users, which is not the operator’s account and not the operator’s money, at the cost of a partner relationship and everything that comes with one. The recipient’s own account, where the payment lands directly in the destination and never rests anywhere else. Or nobody’s: the platform calculates and instructs, and the payer’s own bank pays the recipient, which is the cleanest claim and the weakest automation.

Which of those we end up with is not settled and is not the point here. The point is that I could not have asked the question before I drew the picture. I did not know it was the question. I thought I was choosing a vendor and a schedule, and I was actually choosing a custodian, which is a different kind of decision with a different kind of consequence, made by default if you never notice you are making it.

The phrase I want to retire

This industry, health sharing and cost sharing alike, leans on two phrases that get used interchangeably and mean different things.

No pooled funds is a real, checkable, technical claim. It says nothing accumulates. There is no balance that grows month over month, no float, no war chest that belongs to the operator and gets spent on the operator’s priorities. That claim is worth making, and it is worth holding yourself to.

Money moves directly, person to person is not that claim. It is not even a claim. It is the layman’s picture, and the rails do not implement it. Anyone using it is describing a handler they have chosen not to mention, either because they are hiding it or, far more often and this was me, because they have never drawn the diagram and genuinely do not know it is there.

The two phrases sit next to each other in a lot of marketing copy, mine included, and the first one lends the second one a credibility it has not earned. If you make people a promise about custody, make the custody promise. Do not make the geometry promise. The geometry promise is false for every operator in the country, including the honest ones.

What I actually learned

I did not draw the diagram to find a problem. I drew it to communicate something I was sure of. The diagram deleted the premise instead.

That is the argument for drawing before digging, and it is not the argument I expected to be making. The value was not that the picture organized what I knew. The value was that a picture has slots, and a slot you cannot fill is a fact you do not have. I could hold “money moves directly, member to member” in a sentence indefinitely. I could not hold it in a box for ten minutes.

I had been saying the word directly since the first version of the design. It was doing work the rails cannot do. Nothing about the system changed the day I found out. Every decision downstream of it now starts with a different question.