Implementation
One-off work to get your flows running on the runtime.
- Setup and environment configuration
- Integration with your product and providers
- Migration from existing flows and balances
- Custom flow design
Pricing
Pricing that scales with financial complexity and execution volume.
There is no single price for financial infrastructure. A two-provider payout flow and a multi-rail wallet program carry very different operational risk. This page explains how we charge, even where it cannot say exactly how much.
Most engagements start with a scoped implementation fee, then recurring platform and execution economics as the product goes live.
Commercial model
Four components. You pay for the ones you use.
Platform
A recurring fee for the runtime and the infrastructure behind it.
- Orchestration, execution and ledger
- Proof of Record for operations
- Environments and platform operations
Execution
Economics linked to the operations the runtime executes.
- Transaction-linked or volume-linked pricing
- Reflects the operations you actually run
- Shaped by flow type and provider topology
Advanced capabilities
Capabilities added when your operation needs them.
- Resolve
- Reconciliation automation
- Agent Runtime
- Premium support
- Custom compliance or integration work
We do not publish fixed tiers or per-seat pricing. Seats do not reflect what financial infrastructure costs to run, and fixed tiers would misprice most real deployments.
Scoping
Typical engagements are scoped around use case, provider topology, transaction volume, and required runtime capabilities.
Use case
A single payout flow is a different engagement from a multi-country wallet program.
Provider topology
How many PSPs, banks, wallets and rails are involved, and how they fail.
Transaction volume
Expected volume and its profile, which shapes execution economics.
Runtime capabilities
Which capabilities you need beyond the core runtime, such as Resolve or Agent Runtime.
How engagements start
Start from one flow, not a procurement questionnaire.
Most engagements begin with a conversation about a single flow that is already causing operational work: a payout that times out, a wallet that drifts from provider balances, a corridor with too many manual steps. Pricing follows from that scope.
- Architecture session Your current flow and where it breaks
- Scope Use case, providers, volume, capabilities
- Proposal Implementation, platform and execution terms
- Implementation Integrate, migrate, verify
- Operate and expand Add flows, rails and capabilities
Implementation
What implementation looks like.
Integrate alongside what you run
The runtime connects to your existing PSPs, banks and wallets. Implementation starts with the providers you already use rather than replacing them.
Design the flows
Flows, policies and failure handling are designed with your team, including what happens when a provider does not answer.
Verify before you expand
The first flow is checked against provider reality before more flows, rails or capabilities are added to the scope.
Technical teams can also review concepts and request documentation and API access during evaluation. See the developer surfaces →
Bring your architecture. We will explain the commercial model against it.
Tell us the use case, the providers involved and the volume you expect. We will scope the engagement with you.