by Amr Mohamed
Two of your users each set aside 20% of their income this month. One moved it into a savings account. The other bought equities.
Your systems will file these as unrelated events. One is banking. One is investing. Different product surface, different data model, probably a different team.
They made the same decision. They did not spend a fifth of what came in.
What they now hold is genuinely different. One has liquidity. The other has exposure. That difference matters and you should keep it. But if your infrastructure only sees the difference, you have lost the thing the two users had in common, which is the part that tells you who they are.
Category tells you where, not what
Ask someone what they did with their money last month and they answer in the vocabulary of whichever app they opened. A balance. A return. A wallet transaction.
None of that describes what happened. Money moved. Something was kept, something was risked, something was borrowed against, something was spent. The instrument records where the event took place. It does not record what the event was.
This is not an argument that the rail is noise. A brokerage position and a savings balance behave differently under stress, and reading financial state means holding on to that. The claim is narrower: the instrument is secondary to the intent, and most infrastructure has it the other way around.
What that costs you
Category-first architecture produces a specific failure. Your user fragments into a banking profile, an investing profile, and a crypto profile, and something downstream has to reconcile them.
Someone aggressively paying down debt while quietly building a small equity position looks like two contradictory customers. They are one person making one coherent set of tradeoffs. Reconciliation after the fact rarely recovers that, because the thing that connected the two events was never captured in the first place.
The second cost is coverage. If your read of a user depends on which categories you happen to have, then a thin file is an unreadable user. Read intent rather than instrument and a user who arrives with mostly crypto activity, or mostly one account, is still legible. Less confidently, but legibly.
The primitive is what the person was reaching for
Take three events from the same week. A grocery purchase on a debit card. A stock purchase in a brokerage account. A swap between two crypto assets.
Three systems, three teams, three rulebooks. Read as behavior, the grocery purchase is consumption. The stock purchase is exposure to future value. The swap is the same reach for exposure, wearing a different instrument.
We built the model around that. There is no separate banking system, investment system and crypto system underneath it. There is one way of reading a financial event, with the instrument carried as an attribute rather than a different pipeline.
That read surfaces as a set of signals your product can act on: spend_readiness, save_readiness, invest_readiness, borrow_readiness, stay_quiet. They describe what a user's behavior currently supports, not what anyone ought to do about it. Your product decides what to do with that. We do not decide for it, and we do not decide for your user.
None of this makes category disappear. Tax reporting, regulatory disclosure and custody still care which rail the money moved through. What we are arguing is narrower. For reading behavior, the rail is not the interesting part.