Home

Composable platform and tailored services

Client cases
Blog
Book a demo

Effective business banking solutions require proper capability and integration layers

Orchestration & integration

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

Building for banks since 2016 Bank satisfaction 8.9/10 (TreasurUp Bank Satisfaction Survey, 2025) ISO 27001 certified

Orchestration and capability layer

Orchestration & capability: intelligence making the difference

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

TreasurUp Bank & third-party systems

What it does for your business clients

Four use cases, one pattern

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.

Covered in full on the Foreign Exchange page

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.

Covered in full on the Digital Assets page

How it works, where it sits

Trigger, calculation, destination

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 caseTriggerThe orchestration layer…Routes to
Liquidity managementBalances across accounts, entities, currenciesApplies the client's sweep and pooling rules, calculates group position, flags surplus or deficitCore banking (sweep instructions); RM and client (recommendations)
FX hedgingExposure change from forecast, invoice or instructionCalculates exposure against the client's hedge policy, generates trade request, routes for approvalFX price engine; deal capture
Cross-border paymentsPayment instruction requiring conversionCombines rate sourcing with routing rules, sequences compliance checks, coordinates settlementPayments engine; core banking ledger
Digital assetsFiat and digital asset positions held togetherReconciles balances across both, calculates combined exposure, generates conversion or transfer instructionCore banking (fiat leg); digital asset infrastructure (digital leg)

Value to your bank

Why this layer earns its place

One rules engine across segments

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.

Deeper relationships

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.

Your client stays in control of every rule

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.

Delivered by a solution provider that only serves banks

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

Integration with internal and external platforms

Three groups of systems connect, all through TreasurUp's connection centre.

Core banking

Ledger, account data and entitlements stay where they are.

  • Reads real balances and real entitlements
  • Writes instructions back through the same connections

Product engines

FX price engine, payments engine, deal capture.

  • Never replaced, never the system of record
  • Routes the request, delivers it, reconciles the response

Client systems

ERP, accounting systems, market data feeds.

  • Invoices and receivables feed forecasts and exposure
  • Clients can initiate from their own ERP, same rules and approvals

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

Questions banks ask about this layer

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.

See the orchestration layer applied to your own use case

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.