We built this bank on Smart Contracts

What a Contract-Native Core Means for Banking

By Monica Monica Velasquez, CTO, Afin Bank

The Choice That Defines a New Bank

Every new entrant in financial services faces a foundational technology decision early on. You can license a traditional core banking system, one that has been shaped over decades to serve incumbent institutions and configure your products inside its established catalogue. Or you can commit to a programmable, contract-native architecture where every product is code.

At Afin Bank, we chose the latter. We run on Thought Machine Vault, a cloud-native core banking platform where financial products are not configured through parameter screens or back-office workflows. They are defined as Smart Contracts: deterministic, versioned code artefacts written in a purpose-built language that executes within a secure, sandboxed runtime.

We have been live on this architecture for some time now. What follows is not a theoretical argument for why this approach might work. It is a reflection on what it means to operate a bank on this — what it gives you, what it demands of you, and why it matters.

The Contract Is the Product

This is the single most important thing to understand about Vault. A Smart Contract on this platform is not a wrapper around a product engine. It is not a configuration layer. The contract is the product. It contains the complete financial logic: how interest accrues daily, how payments are allocated between principal and interest, how overpayment thresholds are enforced, how early repayment charges are calculated across product-switch windows, and how the account transitions between states — active, in arrears, early settlement, matured, closed.

If you read the contract, you understand the product completely. There is no secondary documentation required to explain what happens at the boundary conditions, because the boundary conditions are in the code. There is no gap between what was designed and what the customer experiences, because the code is the design.

This sounds simple. It is not. It requires a fundamentally different discipline in how you think about product development. Technical product managers, risk teams, and engineers must collaborate on the contract itself, not on a requirements document that is later interpreted into configuration. The contract is the artefact that goes through review, testing, and sign-off. It is the single source of truth.

Drawing the Right Boundaries

The architectural skill with Vault is not writing the contract. It is knowing what should go into it and what should stay outside it. Get this wrong in either direction and you create problems. An overloaded contract becomes difficult to test, slow to version, and hard to reason about. A thin contract that pushes too much logic into surrounding services creates brittle orchestration layers and loses the auditability that makes the model valuable in the first place.

We learned this through experience. The contract should own the financial product logic, the calculations, the rules, the state machine. Everything else origination decisioning, payment rail integration, customer communication, analytics, AI-driven compliance operates independently in the surrounding ecosystem of services. These concerns evolve at different velocities and for different reasons. Entangling them with the stable, auditable contract creates coupling that undermines the entire architecture.

I will not detail exactly where we draw every line, because that boundary is itself a competitive asset. But the principle is clear: the contract is the financial product, and the ecosystem is everything that serves, feeds, monitors, and extends that product. The boundary between them should be as clean and as intentional as an API contract between two well-designed services.

What This Architecture Gives You

1. Velocity Without Compromise

Changing a product rule can trigger a release cycle that touches the entire product engine. On Vault, Smart Contracts are versioned independently. We can deploy a new version of a fixed-rate mortgage contract without touching the variable-rate contract, without redeploying origination services, and without scheduling a maintenance window. A new product variant is a new contract, it is written, tested, peer-reviewed, and deployed through our CI/CD pipeline with the same rigour and speed as any modern software release.

This is a structural speed advantage. It is not a process improvement bolted onto a legacy platform. It is a property of the architecture itself.

2. Immutable Auditability

Every contract version is an immutable artefact. Once deployed, it cannot be altered, only superseded. Every account is permanently pinned to the exact contract version it was originated under. This gives us a complete, immutable audit trail of the product terms that governed every customer's mortgage from origination. 

3. Testing as a First-Class Discipline

Because Smart Contracts execute in a deterministic sandbox, they are inherently unit-testable in a way that legacy product configurations simply are not. We run parameterised test scenarios against every contract before deployment: leap-year interest accrual edge cases, payment allocation under partial overpayment, ERC calculations across product-switch boundaries, arrears escalation sequences, rate resets at the BoE base-rate change boundary. These tests run in seconds, not hours. 

This is the testing rigour that legacy platforms structurally cannot support, because the product logic is entangled with the infrastructure. On Vault, the product logic is isolated, deterministic, and testable in the way that any well-engineered software module should be.

What It Demands

I would be dishonest if I presented this as a frictionless approach. A contract-native architecture demands things that traditional platforms do not.

It demands engineers who think in financial products, not just code. Writing a mortgage Smart Contract is not a standard software engineering exercise. You need people who understand daily compounding, understand the difference between contractual and statutory ERCs, understand how arrears thresholds interact with collections policy, and can express all of this in deterministic, testable logic. The intersection of deep financial domain knowledge and software engineering craft is not a large talent pool.

It demands a different relationship between product, risk, and technology. The contract is the shared artefact. Technical product managers cannot throw requirements over a wall and expect a configuration team to interpret them. Risk cannot review a product post-hoc by inspecting parameter tables. Everyone works on the contract, or at least reads it. This is a cultural shift as much as a technical one.

It demands investment in tooling, testing infrastructure, and contract lifecycle management that you would not need on a traditional platform. The freedom to define anything also means the freedom to get things wrong, and the safety net is the discipline you build around the process.

The Advantage of Starting Clean

This is what it means to be a new bank. We did not inherit technical debt, vendor lock-in, or architectural compromise. We designed every layer of this stack for the operating characteristics we wanted: real-time event processing, horizontal scalability, infrastructure-as-code, and zero-downtime deployment.

Every capability we build sits on a foundation designed for the next decade, not adapted from the last one. 

Where This Goes Next

The contract-native architecture opens possibilities that we are only beginning to explore. Vault supports supervisor contracts, contracts that orchestrate behaviour across multiple child contracts. This means a customer's mortgage, offset savings account, and insurance wrapper could be governed by a single supervisor that dynamically optimises interest offset, payment allocation, and fee structures as a unified financial position rather than a collection of siloed products.

Composable, programmable financial products that adapt to customer circumstances in real time, governed by auditable code, deployed on infrastructure that scales without constraint. That is the direction of travel. We are building toward it every day.