Custom channel propositions for daily business banking
Composable platform and tailored services
Business Banking services
Federated channel development Advisory and Solution designsManaged services & innovation
Deployment flexibility Security Market-driven innovationEffective business banking solutions require proper capability and integration layers
Your channel shows business clients their balances. The systems behind it execute transactions. The orchestration and capability layer is what turns one into the other: rules your bank configures, exposure calculated across accounts, currencies and entities, and instructions routed to the systems you already run.
Trusted by leading institutions including
Orchestration and capability layer
The layer runs on three components: a rules engine the bank configures, exposure calculations across accounts, currencies and entities, and the generation of requests that route to the bank's own systems for approval and execution. Data and instructions flow in both directions.
Business banking clients
Small businesses and mid-corps: liquidity, FX, cross-border payments and digital assets
Client channels
Business banking portal · Mobile app · Embedded · Agentic
Orchestration & capability layer
Rules engine · Exposure calculations · Instruction generation: sweeps, trade requests, payments, conversions
Integration layer
Connection centre · Verified connections · Reconciliation and source tagging
Core banking
Ledger · Accounts · Entitlements
Bank product engines
FX price engine · Payments engine · Deal capture
Digital asset infrastructure
The bank's digital asset systems
Client & third-party systems
ERP · Accounting · Market data
Core bank engines
Core banking · Bank product engines · Digital asset infrastructure · Client & third-party systems
What it does for your business clients
Each starts with a trigger from the client's real position, applies a rules-based calculation, and produces an instruction that flows to the right system.
Liquidity management
Trigger. Balances across accounts, entities and currencies.
Orchestrates. Applies the client's own sweep and pooling rules, calculates the group position, and flags a surplus or deficit against the thresholds the client has set.
Routes to. A sweep instruction toward core banking, or a recommendation surfaced to the client and the relationship manager: a sustained surplus suggests a term deposit, a projected shortfall suggests a credit line. The recommendation comes from the client's actual forecast position, not a marketing calendar.
Covered in full on the Payments and Liquidity Management page
FX hedging
Trigger. An exposure change: a new forecast, an incoming invoice, or a manual instruction from the client. For clients that run finance inside an ERP, hedging instructions can originate there directly through STP hedging.
Orchestrates. Calculates the exposure against the client's hedge policy, generates a trade request, and routes it through the bank's authorization model: trade input, trade approval, view-only.
Routes to. The bank's FX price engine for pricing and its deal capture system for booking, with the result reconciled back so every system agrees on what happened.
Cross-border payments
Trigger. A payment instruction that requires currency conversion.
Orchestrates. Combines FX rate sourcing with the bank's payment routing rules, sequences the compliance and sanctions checks the bank requires, and coordinates settlement so the FX leg and the payment leg reconcile as one transaction.
Routes to. The payments engine and the core banking ledger. The client sees a single journey; the bank's ledger sees a clean, matched record.
Covered in full on the Payments and Liquidity Management page
Digital assets
Trigger. A client holding both a fiat account and a digital asset position, whether a stablecoin balance, a tokenized deposit, or another digital holding.
Orchestrates. Reconciles balances across the bank's fiat ledger and its digital asset infrastructure, calculates combined exposure across both, and generates the conversion or transfer instruction the bank's policy allows.
Routes to. Core banking for the fiat leg, the digital asset infrastructure for the digital leg, with both settling back into one position view. One workflow inside the bank's own channel, not a redirect to a separate portal.
How it works, where it sits
The layer sits between your client-facing channels, web, mobile, embedded, agentic, and the systems that execute. The same client position that drives a liquidity recommendation can drive an FX hedge and a payment, because it is one layer seeing one client.
| Use case | Trigger | The orchestration layer… | Routes to |
|---|---|---|---|
| Liquidity management | Balances across accounts, entities, currencies | Applies the client's sweep and pooling rules, calculates group position, flags surplus or deficit | Core banking (sweep instructions); RM and client (recommendations) |
| FX hedging | Exposure change from forecast, invoice or instruction | Calculates exposure against the client's hedge policy, generates trade request, routes for approval | FX price engine; deal capture |
| Cross-border payments | Payment instruction requiring conversion | Combines rate sourcing with routing rules, sequences compliance checks, coordinates settlement | Payments engine; core banking ledger |
| Digital assets | Fiat and digital asset positions held together | Reconciles balances across both, calculates combined exposure, generates conversion or transfer instruction | Core banking (fiat leg); digital asset infrastructure (digital leg) |
Value to your bank
The same orchestration layer serves a small business owner who needs a simple guided journey and a mid-corp treasury team that works against a formal treasury policy. Your bank configures which complexity each segment sees. Banks are usually told to choose between simple for small businesses and deep for larger clients; a configurable rules layer removes that choice.
A client whose forecasts, hedges, sweeps and payments all run through one orchestrated layer interacts with your channel daily, not monthly. Switching cost rises with every connected data source and every configured rule, and every forecast position doubles as a precisely timed product conversation: term deposits on surplus, credit lines on shortfall, hedging on currency exposure.
Hedge policies, thresholds, authorization models and routing rules are your client's own configuration. TreasurUp builds and runs the layer that applies them consistently; your client owns what they say. Nothing financial, regulatory or accounting-related is decided by the system on the client's behalf.
TreasurUp works exclusively with banks, so innovations developed with one bank strengthen the propositions of the others. TreasurUp's bank satisfaction rating was 8.9 out of 10 in 2025 (TreasurUp Bank Satisfaction Survey, 2025).
Integration
Three groups of systems connect, all through TreasurUp's connection centre.
Ledger, account data and entitlements stay where they are.
FX price engine, payments engine, deal capture.
ERP, accounting systems, market data feeds.
Every connection is verified on both sides. Every action carries its source: AI-generated, manually adjusted, or client-instructed, so month-end review, CFO sign-off and auditor questions stay answerable.
FAQ
Four use cases tied directly to what business clients ask their bank for: liquidity management (real-time position visibility and sweep or pooling across accounts and entities), FX hedging (exposure calculation against the bank's hedge policy, with trade requests routed for approval), cross-border payments (currency conversion combined with payment routing and compliance checks), and digital assets (bringing a client's fiat and digital asset positions into one reconciled view and workflow). Each use case follows the same pattern: a trigger from the client's real position, a rules-based calculation, and an instruction that flows to the right system.
No. The orchestration layer applies the client's own configured hedge policy and exposure limits to generate a trade request, but a person, not the system, makes the financial decision. When a client's exposure moves outside the bank's set thresholds, the layer calculates the position and prepares the request, then routes it through the bank's own authorization model (trade input, trade approval, view-only) before anything reaches the price engine or deal capture system. The client defines every rule and every threshold.
No, and it isn't designed to. The orchestration layer sits above the bank's core banking system and connects to it rather than replacing it. Core banking keeps the ledger, the account data and the entitlement model exactly as it does today. TreasurUp's layer reads that data, applies the bank's rules, and writes instructions back through the same core banking connections. Banks keep their existing vendor relationships for core banking, price engines and deal capture.
Connections run through TreasurUp's connection centre, the same mechanism used across the composable platform. Three groups of systems connect: core banking (ledger and entitlement data), the bank's own product engines (FX price engine, payments engine, deal capture systems), and third-party systems the client or bank relies on (ERP platforms, accounting systems, market data feeds). Each integration is verified on both sides, so a change on one side doesn't silently break the other.
The orchestration layer coordinates; the price engine or payments engine executes. When a client needs to hedge an exposure or move money cross-border, the orchestration layer calculates the position, applies the rules, and generates the request, but the trade is priced and booked by the bank's FX price engine, and the payment is processed and settled by the bank's payments engine or deal capture system. TreasurUp doesn't replace those engines or become the system of record for pricing or settlement.
It depends on what the connected core banking system and product engines support, since the orchestration layer works with the data those systems make available. Where a bank's systems provide real-time balance and position data, the orchestration layer calculates exposure and generates requests immediately rather than waiting for an overnight cycle. Where a system only updates in batch, the orchestration layer works within that cadence until the bank modernizes the connection.
Yes. The orchestration layer reconciles a client's fiat balances and digital asset positions, calculates combined exposure across both, and generates the instruction needed to convert or transfer between them according to the client's own policy. The fiat leg routes to core banking; the digital asset leg routes to the bank's digital asset infrastructure; both settle back into one position view. This is one workflow inside the bank's own channel, not a redirect to a separate experience.
Bring one workflow your business clients struggle with today, a hedging policy, a liquidity sweep, a cross-border flow, to a working session with TreasurUp's solution architects, and leave with a capability map of how it would run through your channel.