The Programmable Balance Sheet: a framework for banks

For many financial institutions, the challenge of programmable money is not technical. It is connecting the technology with a concrete client need, with existing products and with a model that protects deposits, strengthens the financial relationship and generates business.

This series proposes approaching it through the logic of the balance sheet, the client and the business, in three steps: who keeps the financial relationship, which architecture serves each institution and how to move from architecture to a financial program. The goal is for more banks and credit unions, regardless of their size or where they operate, to be able to add these technologies profitably.

*Originally published in Spanish on LinkedIn as a three-part series: part 1, part 2 and part 3.*

1. Who keeps the financial relationship?

During 2025, Latin America moved approximately US$324 billion in stablecoin transactions, a year-over-year increase of 89%. The figure confirms that this is no longer a marginal technology. Source: OpenTrade, The Stablecoin Surge: Unlocking Growth Across Latin America.

The conversation tends to focus on faster payments. But for a bank or a credit union, that is only the surface.

The strategic question is a different one: who keeps the deposit, the data and the financial relationship when the client begins to operate with programmable money?

The payment changes the experience. The balance sheet defines the business.

When a client converts part of their deposits into a stablecoin, the money does not necessarily leave the financial system. The reserves that back those instruments can remain at a regulated institution.

But they may no longer be at the institution that originated the relationship with that client.

That change matters. The originating institution can lose funding, transactional activity, information about the client's financial behavior and future opportunities in credit, treasury or liquidity management.

The client may keep their account. However, they may begin to move, convert and manage their money from another interface, under other rules and with another provider as the primary relationship.

The point is not to claim that every adoption of stablecoins destroys bank deposits. The point is to recognize that, when the infrastructure on which money moves changes, who captures the activity and who maintains the relationship can change as well.

The decision is not technological

Waiting for greater regulatory clarity is understandable. Legal frameworks continue to evolve, and each market has different conditions.

But waiting does not eliminate the decision. It allows other players to define the experience, the distribution and the client's habits first.

An institution can take one of three positions:

• Stay on the sidelines while others build the new experience.
• Integrate partners' capabilities and keep the primary relationship with the client.
• Use its license, balance sheet and controls to serve fintechs, issuers and new financial networks.

No position is right for everyone. It depends on the regulation, the strategy, the market and the risk appetite of each institution.

What is hard to defend is treating this topic as if it were only a decision about blockchain.

The questions that should reach the board

Before deciding whether to issue, integrate or wait, an institution should answer four questions:

1. Where do we want the deposit to remain? The programmability of money can change where liquidity is concentrated. The institution must define which deposits it wants to protect and which products it can build around them.
2. Who will keep the transactional data? Payments reveal behavior patterns, liquidity needs and product opportunities. Whoever controls the experience can control a relevant part of that information.
3. What relationship do we want to have with the client? Not every use case requires a proprietary solution. But each institution must decide whether it wants to be the primary relationship, the infrastructure provider or a secondary participant.
4. What financial capability do we want to build? The value is not only in moving money faster. It is in offering treasury, FX, custody, conditional credit and compliance on a programmable infrastructure.

The opportunity does not consist only of defending the existing relationship. It also makes it possible to create new products and to better serve corporate clients, fintechs and issuers.

The answer does not begin by choosing a technology. It begins with a balance sheet problem, a specific client and a decision about the role the institution wants to occupy.

2. The architecture must adapt to the balance sheet

Once the question of who keeps the financial relationship reaches the board, another one appears:

Which architecture truly serves our institution's business?

Stablecoins, tokenized deposits and integration with external providers are often presented as similar alternatives. They are not.

The first two are different money architectures. The third is a go-to-market approach. Confusing them can lead to building a product that is technically attractive but economically disconnected from the balance sheet.

Regulated stablecoin: reach and portability

A regulated stablecoin is backed by a dedicated reserve and seeks to maintain parity with a currency. Depending on the jurisdiction, it can be issued by a bank or a non-bank entity.

Its main advantage is distribution.

It can move across platforms, connect with wallets, facilitate international payments and serve as a foundation for global financial programs. It is an especially relevant architecture when the institution wants to serve external ecosystems, enable digital payments or launch products with fintechs and platforms.

But that reach has an economic consequence.

The funds that back the stablecoin must be held in reserve under the applicable rules. The institution can capture revenue from issuance, custody, distribution, FX or associated services. However, that model is not equivalent to taking in a traditional bank deposit and using it within credit intermediation.

For that reason, a stablecoin can be an excellent tool for reach. But it should not be evaluated as an automatic substitute for the bank balance sheet.

Tokenized deposit: programmability over the bank liability

A tokenized deposit is a digital representation of an existing deposit. The client keeps a direct claim on the issuing bank, under the institutional and regulatory framework that applies to that bank liability.

The difference seems subtle, but it changes the conversation.

The institution is not creating money backed by a separate reserve. It is enabling its own bank liability to circulate and execute programmable conditions.

This can enable 24/7 corporate payments, settlement among authorized participants, more efficient treasury and operations linked to tokenized assets. It also preserves the relationship among deposit, balance sheet and intermediation capacity, subject to the rules of each jurisdiction.

The challenge lies in reach.

A tokenized deposit can work very well within a controlled ecosystem or among institutional participants. But to operate across banks, platforms and jurisdictions, it needs shared standards, interoperability and clear settlement rules.

The question is not whether the tokenized deposit is superior to a stablecoin. The question is whether your institution needs to prioritize control over its liability, external portability or a combination of both capabilities.

External integration: speed with clear responsibilities

Integration with an external issuer or provider is not a third form of money. It is an execution route.

It can allow a bank or credit union to validate a use case more quickly, without building all the infrastructure from scratch. It is a reasonable way to begin, especially when the goal is to learn, test a concrete client need and measure results.

But integrating does not mean delegating strategy.

Before launching, the institution must define precisely who controls the client experience, the transactional information, compliance, custody, the conversion process, liquidity and responsibility toward the user.

If the partner controls everything the client sees and uses, the institution may end up funding a relationship that another player captures.

The question that defines the architecture

There is no universal answer.

A regulated stablecoin may be suitable for global distribution and connection with external ecosystems. A tokenized deposit may be more relevant for institutions that want to preserve their liability and develop programmable corporate products. An external integration may offer a faster way in, provided that the institution keeps control over the elements that truly matter.

The technology must adapt to the institution's balance sheet, risk appetite and P&L. Not the other way around.

The right architecture is the one that solves a real client problem, protects or expands the financial relationship and can become a defensible business.

3. From architecture to a financial program

Choosing an architecture is not the end of the decision. It is the starting point.

The question that follows is more important: which problem of our clients will we solve with this capability, and how will it become a business for the institution?

There is no single catalog of use cases and no recipe valid for everyone. Each bank or credit union must begin where a real need in its portfolio, a capability it wants to strengthen and a defensible regulatory route converge.

The following are two possible entry points.

Corporate treasury and 24/7 liquidity

For a company that operates in several markets, the problem is not the technology. It is the daily friction of managing payments, suppliers, currencies and liquidity at different hours.

Programmability can help move funds outside banking hours, automate authorization rules, concentrate cash and execute FX under predefined conditions.

For the institution, this use case opens a broader conversation than a fast transfer. It makes it possible to offer treasury, FX, compliance and liquidity management services around the client's primary relationship.

The goal should not be to force the corporate client to learn how a blockchain works. The goal is for the client to experience a better financial service while the institution keeps the deposit, the data and the opportunity to expand the relationship.

This can be an attractive entry point for institutions with corporate clients, cross-border merchants or platforms that need to manage mass payments. But it is not the only one.

Programmable credit and collateral

Another entry point is on the asset side of the balance sheet.

In trade finance or supply chain finance, an institution can make a disbursement conditional on verifiable events: an approved invoice, a customs document, the delivery of goods or a confirmation within the client's ERP.

The technology makes it possible to connect those conditions with the execution of funds. This can reduce manual steps, improve traceability and provide greater visibility into the status of an operation.

It can also be applied to collateral management, margin calls and short-term settlements.

J.P. Morgan, for example, offers intraday repos through Kinexys Digital Financing, with programmable terms and delivery versus payment. It is not a model that every institution should replicate immediately. It is a signal that the infrastructure now makes it possible to coordinate cash, collateral and maturities in ways that were previously difficult to operate.

Other use cases may emerge in custody, cross-border payments, distribution of financial products, collections, disbursements, remittances, programmable accounts or services for fintechs. The priority depends on the client portfolio and on the capability the institution wants to build.

Technology does not replace banking judgment

Programmability can automate instructions. It does not eliminate risk.

Credit still requires analysis. Collateral still requires valuation and custody. Settlement still requires legal certainty. And a 24/7 operation demands liquidity, compliance and operational continuity controls at the same speed.

For that reason, an initiative should not start with the question "What can we tokenize?"

It should begin with more useful questions:

• What relevant friction does our client experience?
• Which product or relationship do we want to protect or expand?
• What economic result do we expect for the client and for the institution?
• Which capabilities must we control, and which can we integrate?

The programmable institution does not build everything alone

A bank or credit union contributes its license, balance sheet, compliance and trust.

A fintech can contribute product experience, speed and distribution.

The program needs to integrate both capabilities under a single business case.

At FlouLabs, we do not only help design that execution; we connect Legal, Risk, Credit, Treasury and Technology so that an initiative can be approved, launched, operated and measured. We also provide access to our financial infrastructure so that your institution can launch its solution in weeks, not months.

The programmable institution is not the one that uses the most technology. It is the one that knows where that technology creates value for its client and for its balance sheet.