Beyond Virtual Accounts: How Banks Can Monetise Programmable Settlement Services

Virtual accounts have given corporate banking teams a compelling proposition.

They help businesses organise incoming payments, improve reconciliation, create more granular cash visibility and simplify complex account structures. For corporate treasurers managing multiple entities, customers, projects or business units, these capabilities can make a material difference.

But there is a bigger commercial opportunity.

What happens after the money has been identified?

Which obligations should be funded? Which suppliers should be paid? What conditions must be met before a payment is released? How should a receipt be divided between several beneficiaries? And how can the bank help its customer coordinate these decisions without relying on manual instructions and disconnected systems?

These are not simply account-management questions. They are settlement and business workflow questions.

Virtual accounts help banks organise money. Programmable settlement services give banks an opportunity to monetise what happens to that money.

The transaction banking revenue opportunity

Transaction banking is already a significant source of revenue for financial institutions. It brings together payments, cash management, liquidity services, deposits and trade finance.

McKinsey estimated global transaction banking revenue at almost $1.3 trillion in 2024, representing close to half of wholesale banking revenue. Its 2025 analysis also highlights the importance of growing fee income as banks respond to interest-rate uncertainty, changing customer expectations and more intense competition.

The commercial challenge is not simply to process more transactions. It is to capture more value from the corporate workflows that generate those transactions.

Banks have traditionally monetised services through payment charges, account fees, foreign exchange spreads, liquidity products and trade finance fees. These remain important. But corporate customers increasingly expect banking capabilities to integrate with the systems and processes through which they run their businesses.

That creates room for a new layer of services: configurable settlement workflows that help customers manage how money moves through their operations.

Why virtual accounts are only the starting point

Virtual accounts provide a useful foundation. They can create unique identifiers or sub-ledger structures for customers, invoices, projects, business units and other purposes without requiring a separate physical bank account for every relationship.

Banks already package these capabilities into cash management propositions.

For example, HSBC positions virtual accounts around receivables reconciliation, centralised payment processes and treasury visibility. ING's virtual cash management services support cash concentration, automated allocation and multi-entity oversight. Bank of London describes virtual account hierarchies, API access and on-demand account creation for corporate cash management.

These are valuable services, but they principally address the organisation and visibility of funds.

Consider a company that receives a £500,000 customer payment into a virtual account associated with a project.

The bank may identify the payment, associate it with the project and update the relevant balance. But the company still needs to determine how much should be reserved for materials, which supplier should be paid, whether a delivery milestone has been met and when the remaining funds can be released.

The virtual account provides visibility. The settlement workflow governs what happens next.

That distinction creates the opportunity to move from charging for account structures towards charging for business outcomes.

Five ways banks could monetise programmable settlement

The following are potential product and revenue models, not prescribed pricing tariffs. Banks would need to validate willingness to pay, implementation costs, transaction economics and applicable regulatory requirements for each proposition.

1. Charge for configurable settlement workflows

Banks could introduce premium workflow services that allow corporate customers to define rules around how payments are allocated, approved and released.

Examples include:

• Supplier payments released after authorised delivery confirmation.
• Escrow-style arrangements with predefined release conditions.
• Milestone-based payments for construction and engineering contracts.
• Automated allocation of incoming receipts across agreed beneficiaries.
• Commission and fee deductions before final settlement.

The commercial model could combine a recurring workflow subscription with usage-based fees for executed settlement events.

The value proposition is not simply that a payment happens faster. It is that the bank helps remove manual coordination from a commercially important process.

2. Monetise multi-party settlement

Many corporate transactions involve more than two parties.

A single customer receipt might need to be distributed between a principal supplier, logistics provider, agent, subcontractor and platform operator. Each party may have a different entitlement, payment condition or approval requirement.

Banks could offer multi-party settlement as a premium transaction banking service, charging through transaction fees, beneficiary fees or a bundled service subscription.

This could be particularly relevant to:

• Construction and infrastructure projects.
• Import and distribution networks.
• Procurement and supplier ecosystems.
• Marketplaces and franchise networks.
• Insurance and claims disbursement arrangements.

The opportunity is to make the bank a more useful participant in complex commercial transactions, rather than simply the institution through which the final payment passes.

3. Offer reconciliation and financial control as a service

Reconciliation is often treated as a back-office function. For corporate customers, however, poor reconciliation creates operational friction and delays financial decision-making.

Banks could extend their virtual account propositions with services that connect payment identification to settlement records, beneficiary allocations and transaction status.

Potential chargeable features include:

• Automated matching of receipts against invoices or orders.
• Project-level allocation and reporting.
• Exception management and unresolved-payment workflows.
• Consolidated settlement statements.
• API-based access to transaction and reconciliation data.

This could be packaged as a premium reporting and reconciliation service, with pricing based on transaction volumes, account structures, reporting frequency or API usage.

McKinsey's research into B2B banking APIs found that customer fees and ecosystem revenue sharing were already established monetisation approaches among surveyed banks. Its findings also point to the opportunity to build more sophisticated services around existing payment and account APIs.

4. Bundle programmable settlement with treasury and liquidity services

This is where the opportunity becomes particularly interesting for corporate banking product teams.

When a bank can identify incoming funds, understand their intended purpose and coordinate outgoing obligations, it has a stronger foundation for offering more sophisticated liquidity services.

For example, a business might configure rules to:

• Reserve a defined amount for upcoming supplier obligations.
• Transfer surplus balances according to agreed thresholds.
• Allocate project receipts to separate operating requirements.
• Coordinate funding across subsidiaries.
• Trigger payments when approved obligations become due.

These services could be bundled with cash pooling, liquidity forecasting, sweep arrangements and other treasury products.

The bank could monetise the proposition through premium treasury service fees, account packages and transaction charges. Any interest or float-related income would depend on the underlying deposit, liquidity and regulatory arrangements; it should not be assumed simply because a settlement workflow is automated.

5. Create industry-specific transaction banking products

A general-purpose programmable settlement engine can support different commercial workflows. Banks do not need to sell the underlying technology as a generic feature.

Instead, they can package it around the needs of particular industries.

Industry	Potential banking proposition	Monetisation opportunity
Construction	Project-based receipts, subcontractor allocations and milestone payments	Project workflow subscriptions and settlement fees
International trade	Conditional supplier payments linked to trade documentation and shipment events	Trade service fees, FX and transaction charges
Distribution	Automated allocation of collections and supplier disbursements	Collection, reconciliation and payout fees
Marketplaces	Multi-party settlement, commissions and conditional release	Platform subscriptions and per-settlement fees
Insurance	Claims allocation and controlled beneficiary disbursement	Claims processing and payment service fees

Industry-specific packaging gives relationship managers a more concrete proposition to take to customers. It also helps banks compete on business understanding and service design rather than payment price alone.

What might the commercial model look like?

There is no single pricing model that will suit every programmable settlement service.

A bank could combine several approaches, depending on the value delivered and the complexity of the workflow.

Revenue model	What the bank charges for	Suitable application
Subscription	Access to a defined service tier or workflow capability	Corporate settlement packages
Per transaction	Each payment or completed settlement	Supplier and beneficiary payments
Per event	Each validated milestone, approval or release event	Conditional settlement
API usage	Calls, data access or integration capacity	ERP and treasury integrations
Premium reporting	Reconciliation, analytics and consolidated reporting	High-volume corporate customers
Revenue sharing	Commercial value generated with an ecosystem partner	Embedded banking and platform partnerships

The strongest proposition may combine a predictable recurring fee with usage-based charges.

A subscription creates a more stable revenue relationship. Usage-based pricing allows revenue to grow as the customer's transaction activity increases. Premium features provide room to differentiate service tiers.

However, pricing should follow measurable customer value rather than the technical complexity of the underlying software.

A customer is unlikely to pay a premium simply because a bank has introduced a rules engine. They may be willing to pay when the service reduces manual payment administration, accelerates supplier settlement, improves reconciliation or gives them greater control over contractual obligations.

The UK and European market: signs of commercial direction

There are already examples of banks extending account infrastructure into more sophisticated corporate services.

HSBC's virtual account proposition supports receivables and payable processes, centralised cash management and reconciliation. ING combines virtual accounts with cash concentration, liquidity visibility and automated allocation. Bank of London offers API-accessible virtual account hierarchies and flexible account structures for corporate operating models.

These examples demonstrate that banks are already packaging account infrastructure as a commercial treasury service.

At the wider payments infrastructure level, the Bank of England's June 2026 consultation on future retail payments infrastructure also identifies programmability as an important capability. It highlights patterns such as conditional hold and release, enriched payment messaging and the need for clear failure and timeout handling.

The direction is significant: the infrastructure conversation is moving beyond speed and connectivity towards the ability to support more intelligent payment journeys.

The commercial opportunity for banks is to turn these capabilities into products that corporate customers can understand, adopt and pay for.

The infrastructure question: build every workflow or orchestrate them?

A bank could attempt to develop each programmable settlement use case independently.

But doing so risks creating multiple bespoke integrations, separate rules engines and fragmented operational processes.

A more scalable approach is to introduce a reusable orchestration layer that can support different settlement policies across existing account and payment infrastructure.

This layer needs to coordinate:

• Incoming value and transaction references.
• Configurable settlement rules and permissions.
• Authorised business events and external system updates.
• Payment instructions and beneficiary allocations.
• Exceptions, failed instructions and retries.
• Audit records and reconciliation outputs.

The bank continues to own the regulated account relationship, custody of customer funds, payment execution and applicable compliance controls. The orchestration layer coordinates the configured business logic and settlement instructions within the agreed operating model.

This separation allows product teams to develop new services without requiring a new settlement architecture for every commercial use case.

Where Pepparest fits

Pepparest is Peppa's conditional payment orchestration engine.

It is designed to collect inbound value, apply configurable logic such as splits, escrow conditions, commissions and compliance-related checks, and coordinate settlement release when the configured conditions are satisfied.

For banks, the opportunity is to use this infrastructure as an enabling layer for programmable settlement services built around their existing banking relationships.

Rather than positioning Pepparest as another virtual account product, the proposition is to help banks extend the commercial functionality of their existing account and payment infrastructure.

A bank could use the engine to support conditional supplier payments, multi-party settlement, project-based disbursements and other rule-driven financial workflows.

Peppa operates as enterprise software middleware. Regulated accounts, fiat custody, foreign exchange and compliance validations remain within the perimeter of licensed partner institutions, according to the deployment and applicable arrangements.

The objective is straightforward: give banks a reusable foundation for creating differentiated transaction banking products without having to build every settlement workflow from scratch.

Explore the Pepparest conditional payment orchestration engine and Peppa's enterprise architecture.

The strategic question for transaction banking leaders

Virtual accounts have helped banks improve how corporate money is identified, organised and reconciled.

But the next competitive advantage may come from helping customers control what happens to that money.

For Heads of Transaction Banking, Corporate Banking Product Directors and Heads of Digital Banking, the opportunity is to look beyond account functionality and identify the commercial workflows that customers would pay to automate.

Start with three questions:

1. Where do corporate customers still rely on manual instructions to allocate, approve or release funds?
2. Which of those workflows could become a repeatable, fee-generating banking service?
3. What orchestration capability would allow the bank to deliver that service across multiple customers and industries?

The banks that answer these questions well could create more than another digital banking feature. They could build a new layer of transaction banking services around the movement, control and settlement of corporate money.

The opportunity is not just to provide businesses with better accounts. It is to monetise the financial workflows those accounts make possible.

---

Frequently asked questions

How can banks monetise programmable settlement services?

Banks can monetise programmable settlement through recurring service subscriptions, per-transaction or per-event fees, premium workflow features, API access, reconciliation and reporting services, and bundled treasury or industry-specific solutions. The right model depends on customer value, transaction volumes, operational costs and the bank's regulatory and payment arrangements.

What is the difference between virtual accounts and programmable settlement?

Virtual accounts primarily help identify, organise and reconcile money within a bank's account structure. Programmable settlement adds configurable rules that determine how funds are allocated, held, released or distributed in response to authorised instructions and business events. The capabilities can work together, but they solve different problems.

How can banks introduce programmable settlement without replacing their core banking systems?

A bank can integrate a settlement orchestration layer with its existing account, ledger and payment infrastructure. The bank retains responsibility for regulated accounts, custody, payment execution and compliance controls, while the orchestration layer coordinates configured rules, events, settlement instructions and records.

---

Sources and further reading

• McKinsey: Charting a path to increasing transaction banking value by 50 percent (September 2025)
• McKinsey: From tech tool to business asset — how banks are using B2B APIs to fuel growth
• Capgemini: Instant payments — the monetization imperative for banks
• Bank of England: Consultation on the design of the future retail payments infrastructure (June 2026)
• HSBC: Virtual Accounts
• ING: Virtual Cash Management
• Bank of London: Virtual Account