The Anti-Vendor Stack is a deliberately composable fintech architecture in which every component — sponsor bank, processor, ledger, KYC, card production, dispute handling — can be swapped without breaking the program. It is the architectural expression of the Software as a Relationship pillar: if the relationships are the asset, the software must be modular enough to keep them.
The test isn't "can I swap a vendor?" It's "have I swapped one, recently, and would my regulator notice?"
TL;DR
- Vendor lock-in in fintech is rarely about migration cost. It's about regulatory inertia: the contract chain that holds your program up is the chain you are afraid to disturb.
- A truly composable stack treats every component as a replaceable interface. That includes the sponsor bank, the processor, and yes — the orchestration layer (us).
- The test of an anti-vendor stack is not "can I swap a vendor?" It's "have I swapped one, recently, and would my regulator notice?"
- This pillar collects the patterns and anti-patterns. Standard interfaces, ledger ownership, dispute-data portability, and the contract clauses that quietly kill optionality.
What's coming here
The full piece will cover:
- A reference architecture for a fully composable fintech stack (with a diagram you can actually use)
- The standard interfaces that need to exist between sponsor-bank, processor, ledger, and program-management layers
- Contract clauses that quietly destroy optionality (data ownership, exit notice periods, residency, IP, code escrow)
- A self-audit founders can run today to figure out where their lock-in actually lives
- Why Chisel deliberately positions itself as replaceable — and why that's a feature, not a bug
If your stack can't be partially un-built without taking the program down, you don't have a stack — you have a vendor.
Full piece forthcoming. In the meantime, see Software as a Relationship for the worldview and Builder Economics for the math.
— Darin