No. Most prototypes start from a business concept and the ambition behind it, not a requirements document. TreasurUp's business banking and treasury background is what lets a first version land close to right quickly, and the prototype itself becomes the basis for finetuning the concept, the business case and client validation.

Hackathons work best for technically complex challenges where feasibility itself is the open question, inside a bank's actual architecture and its security and reliability requirements. They are shaped around each bank's preferences for location, duration and team composition, and often become the starting point for a longer working relationship rather than a one-off event.

Advisory, prototyping and hackathons are often how a bank and TreasurUp first learn to work together. Where that collaboration continues, it typically moves into a federated development model, with a shared team and a shared backlog across the bank's channel roadmap.

Because an agent is only as good as the platform and data beneath it. The composable banking platform runs the channels and modules for cross-border payments, liquidity management and FX trading; the intelligence engine is the shared domain AI, rules and forecasting capability every agent draws on. Agentic Daily Business Banking is the third layer on top, which is why it can go live as a configuration and rollout step rather than a new procurement.

TreasurUp's orchestration layer is model-agnostic by design, and three deployment shapes are available. Single-tenant deploys the full platform inside your own cloud account, with data never leaving your perimeter. Bring-your-own-LLM lets you choose the foundation model, a private model, or a multi-vendor mix. Hybrid combines TreasurUp-hosted orchestration with bank-hosted data and inference, for the speed of a managed platform without compromising data residency.

Governance is platform spec, not an afterthought. Components are catalogued by criticality and resilience-tested, with incidents streamed to the bank's SIEM under DORA alignment. Model risk management covers model inventory, validation datasets, drift and accuracy monitoring, override and rollback. Every query, retrieval, reasoning step, proposal, approval and executed action is captured end to end, and reasoning is shown in plain language at the point of decision, not buried in logs.

These are the three transaction categories where the daily relationship is most contested. Business owners already route them to fintechs and ERP or accounting tools one workflow at a time, and each workflow that leaves is a relationship the bank no longer owns. They are also where TreasurUp's composable platform already runs live at other banks, so the agentic layer extends what is live today rather than starting from a blank page.

Client Pulse reads behavioural data from your business banking channel: logins, saved-but-unexecuted batches, quote-to-trade ratios and module adoption, baselined per client against that client's own history. This is data external tools cannot see, because it lives inside the transaction initiation environment itself. You can enrich it with your own sources, such as trade or client databases, connected through the TreasurUp connection centre over MCP. Industry averages and fixed thresholds are deliberately not used.

Yes. Your bank owns the agent: branding, data, model choice and deployment topology are yours. Bring your own LLM, and deploy as managed SaaS, single-tenant or hybrid, depending on what your risk and infrastructure teams require. Your data stays within the boundaries you set, and model calls route to the provider you have approved.

Your CRM sees what someone typed in after the fact. Client Pulse sees what the client actually did in the channel: a batch saved but never executed, a hit ratio that started slipping, a regularly traded pair that quietly disappeared. Those signals appear before they show up in trading data or a CRM note, which is the difference between a retention call and a post-mortem. Client Pulse complements the CRM rather than replacing it, and its output can feed your existing RM workflow.

Today Client Pulse runs on FX, because that is where TreasurUp is live inside bank channels and where the behavioural data is richest. The signal model itself is not FX-specific: baselines per client, adoption patterns and activity trends apply to any product a client uses in the channel. TreasurUp is extending Client Pulse to all other areas of Daily Business Banking, including payments, liquidity and cash flow forecasting, so the same weekly priority view grows to cover the whole relationship rather than one product line.

Weeks, not quarters, for a pilot: Client Pulse is the build already underway, and it starts from behavioural data your channel produces today, so a pilot needs a connection rather than a data programme. Full TreasurUp solutions typically go live in 3 to 9 months, compared with 48 to 60 months for comparable in-house builds (Deloitte, 2025). The pilot's job is to answer one question with your own portfolio: which clients should my RMs call this week, and what should they say.

Five use case families: cross-border and intra-group liquidity, including 24/7 on-chain intra-group cash sweeping; excess liquidity optimization through money market funds and tokenized money market funds; wallet visibility alongside fiat account data; stablecoin-to-stablecoin and stablecoin-to-fiat conversion; and on-ramp and off-ramp between fiat and digital assets. Together they cover the full liquidity lifecycle: moving money, optimizing it, seeing it and converting it.

Because the infrastructure is not the hard part. Onboarding a custody or exchange provider is straightforward; connecting it to your core banking systems and business banking portal in a compliant, bank-branded way is what turns infrastructure into a use case your clients actually adopt, and that is the specific gap TreasurUp closes. Building that orchestration and compliance layer in-house is possible, but it takes years most banks do not have, while non-bank fintechs are already capturing the business client relationship.

No. Every use case runs inside the channels your clients already trust: your business banking portal, your APIs and your mobile channel, under your brand. Wallet balances appear next to fiat accounts, conversions run in the same environment as payments, and your staff manage it all through a bank-side admin and operations portal. Your clients never leave your bank to use digital assets.

Significantly less than an in-house build, because the orchestration engine, compliance logic and provider integrations already exist. The practical sequence is to launch one use case first, wallet visibility or on-ramp and off-ramp are common starting points, and extend across the five families on the same orchestration layer. The scoping walkthrough gives you a concrete timeline for your stack and chosen provider.

No. The portal remains necessary. The Connection Centre extends what the portal already offers into the ERPs, accounting systems and other platforms your business clients use, so it is not a choice between the two.

Micro apps place bank functionality directly inside a third-party platform, such as payables management, cash flow forecasting, order and invoice hedging, or excess liquidity investment, so the bank becomes a native part of the client's own workflow.

MCP is a wrapper around TreasurUp's APIs that exposes bank data and capabilities to AI models and agents, so a bank's agentic AI layer can interact directly with data and services.

Through one of four routes: more than 25 REST APIs, an MCP wrapper for AI models and agents, file-based protocols such as SFTP and XML, or a micro app that runs natively inside the platform.

Because AI-generated forecasting, target balancing, other-systems connectivity and cross-sell logic tied to a live cash position are already built and running in production at other banks, buying converts a multi-year build into a delivery your team can plan against this year. Your engineering effort goes into your bank's differentiated capabilities under the same federated model, while TreasurUp owns and maintains the parts common across banks. You keep the channel, the brand and the client relationship throughout.

It sits inside your existing channel as a composable module, not a separate product with its own login, so it extends your current offering rather than replacing it. It connects to your existing core banking and payment rails and to the client's ERP and accounting systems, and surfaces cross-sell opportunities against products you likely already sell. The module fills the forecasting, target balancing and consolidated-visibility gaps most suites don't cover today.

Most engagements begin with a discovery and fit phase of two to four weeks: workshops, a channel audit, and capability mapping against your product suite and roadmap. Banks typically bring payments initiation or liquidity visibility live first, since it proves the architecture fastest. Cash flow forecasting and the cross-sell recommendations layer on top once that foundation is live, with the build risk already retired before your team starts.

Your bank keeps regulatory ownership throughout. TreasurUp designs, builds and operates with DORA, MiFID II and GDPR treated as constraints from the architecture phase, and as an ICT third-party provider to the bank under DORA, delivers to that contractual obligation directly. Your compliance and risk teams set the requirement, and TreasurUp delivers to it, rather than the module arriving as a retrofit to reverse-engineer.

It's built to grow the pie. The recommendations it surfaces, term deposits, credit lines, FX hedges, point RMs toward products your bank already prices and sells, generated at the moment a client's cash position supports the conversation, so it increases conversion and frequency rather than introducing a competing product. The stickiness effect, a higher switching cost once a client's cash flow runs through your channel, also protects the balances and fee income you already hold.

Yes. Managed SaaS, self-hosted/single-tenant, hybrid, on-premise and regulated public cloud all run the same platform, same modules and same support model. Deployment choice changes where it runs, not what it does, and bring-your-own-LLM works across any of these shapes.

Components are classified against DORA criticality tiers and the EU AI Act's risk tiers, with the documentation banks need for high-risk system obligations. We support TLPT-style resilience testing and stream incidents into the bank's existing SIEM through standard interfaces. Every automated component carries a registered specification, and banks can run independent validation, monitor for drift, and disable, override or roll back any component without TreasurUp involvement.

From a team combining former treasurers, commercial bankers and technology specialists, and from the corporates and finance professionals who use these channels day to day across TreasurUp's bank clients, including Nordea, Handelsbanken, Rabobank, KBC, OP, LBBW and Sparkassen. An innovation proven with one bank's clients becomes available to every bank on the platform through frequent releases and co-innovation sessions.

Typically weeks, not quarters, backed by a >99.95% uptime SLA. The API-first architecture avoids a core overhaul, which is what keeps deployment fast regardless of which of the five deployment shapes you choose.

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.