Account types as a primitive

Ask an engineer who has integrated traditional financial systems how many ways there are to open an account, and the honest answer is: as many as there are account types. Retirement lived in one system, brokerage in another, custody in a third, each with its own data model, its own onboarding, its own quirks. Every new product meant a new integration. The account type was treated as an architecture.

One object, every type

A8 Core™ inverts that. There is one Account object, and the account type is a value on it. The same operations open, read, update, fund, and transact against a Roth IRA, an HSA, a trust account, a custodial account, or a brokerage account. You do not learn a new integration per product; you change one field.

"ClientId": "8fa2c1e4-...",
"AccountType": "Roth",
"ProviderReferenceId": "acct-10293"

Change AccountType to HSA, Trust, Custodial, or Brokerage and the call is otherwise identical. The shape of the request, the response envelope, the funding operation, the webhooks — all the same.

What varies, and what does not

Making the account type a primitive does not mean pretending the types are identical. They are not: a retirement contribution carries a TaxYear; a custodial account has a beneficiary relationship; an entity account has different screening. The discipline is to push that variation into data rather than into separate systems. The fields that differ are fields; the operations that act on them are constant.

• Constant: create, read, update, fund, transact, balances, webhooks, the response envelope.
• Varies as data: tax-year semantics, beneficiary structure, screening requirements, eligible payment methods.

Why builders care

When the account type is a primitive, your product roadmap stops colliding with your integration roadmap. Want to add an HSA alongside your existing IRA offering? It is a new value, not a new project. Want to layer custody under a wealth product? Same core, same calls. The cost of a new account type collapses from “another integration” to “another enum.”

Primitives compound. Every capability you build on one account type you get on all of them, for free.

Composability is the dividend

Because every type sits on the same core, they compose. A single verified client can hold accounts across types. A sponsor investment can link to an account regardless of its type. Custody and private-fund accounts reach the same ledger as a brokerage account. The platform does not have to special-case combinations, because there are no separate systems to reconcile in the first place.

This is what “primitive” really means in software: not the smallest thing, but the thing everything else is expressed in terms of. Get the account primitive right and the rest of the product surface becomes recombination rather than reconstruction.