Participant accounts
Programmable accounts for buyers, sellers, and providers, each with its own identity, permissions, and delegated access. Non-custodial by default.
A marketplace moves money between buyers, sellers, providers, and the platform itself, often across borders, currencies, and rails. OVAAL coordinates the accounts, payouts, approvals, and reconciliation that hold it together, on one control plane embedded under your own license. Each participant gets an account; every payout runs through policy; the whole thing reconciles on one operational record.
OVAAL is a technology and orchestration platform, not a bank, EMI, or CASP. Regulated services are provided by appropriately authorised customers and third-party providers. Availability depends on jurisdiction, provider approval, and service scope.
Take the whole control plane or the modules you need. Providers and rails plug in beneath each one.
Programmable accounts for buyers, sellers, and providers, each with its own identity, permissions, and delegated access. Non-custodial by default.
Pay many participants across eligible providers and rails, routed on cost, eligibility, availability, and observed performance, including split and scheduled payouts.
Hold, release, and approve payouts under the rules you define: by participant, amount, condition, or counterparty. Every action previews, logs, and can be revoked.
One operational record across every participant and provider, so platform fees, seller balances, and payouts tie out without a manual stitch-together.
Connect KYC, KYB, sanctions, screening, and Travel Rule workflows for your participants through configurable integrations you operate under your own authorisation.
Integrate through versioned APIs, SDKs, webhooks, sandbox tooling, and implementation support. Exportable data, with a self-host path on the roadmap.
A marketplace isn't one payer and one payee. It's a network. The control plane treats it that way: a payment can split across sellers, a payout can wait on an approval, and a refund can reverse cleanly, all on the same record.
A payments provider for collections, a separate payouts provider for sellers, manual holds for disputes, and a finance team reconciling participant balances by hand across exports that never quite match.
Participants, payouts, approvals, and reconciliation coordinated through one control plane. Policy decides what releases and when; one record shows where every amount sits.
OVAAL is the technology layer. Your license owns the regulated relationship. Authorised providers execute the regulated service. We make the split explicit before the first call.
| Activity | Customer (you) | OVAAL | Authorised provider |
|---|---|---|---|
| Regulatory permissions | Primary for your platform model | Technology role unless expressly authorised | Primary for the outsourced regulated service |
| KYC / KYB of participants | Policy owner | Workflow orchestration | Verification where contracted |
| Holding / safeguarding of funds | Per your model and authorisation | No, unless expressly authorised | Primary where applicable |
| Payout routing & approvals | Oversight and commercial choices | Rules engine and approval workflow | Execution eligibility |
| Reconciliation | Review and finance ops | Platform record and workflow | Source confirmations |
| Support & complaints | Primary | Technical escalation | Service-specific escalation |
Book an architecture review and we'll walk through participant accounts, payout routing and approvals, the reconciliation model, the responsibility split, and a realistic integration path. Prefer to read first? The integration brief is a one-page PDF covering modules, the responsibility model, and indicative commercials.