Platform

Four things a regulated
payments business must do.

Launch it, operate it, connect it, and prove it. Payzone is organised around those four, and every capability below carries the state the platform itself records — operational, staged, or on the roadmap. Nothing on this page is written by hand.

The four packages
  1. 01

    Launch

    For an organisation standing up a regulated payments operation. Entity, principal and agent hierarchy modelled to the permissions you hold; compliance configuration; branding; user training; credential issuance and first integration.

    Engagement
  2. 02

    Operate

    The daily operations platform. Customer due diligence, screening, transactions, maker–checker approvals, case management, settlement, reconciliation and regulatory reporting.

    Platform
  3. 03

    Connect

    The rails and vendors. Payout providers, screening, identity verification, messaging and accounting, integrated once behind a canonical contract so a provider change is a configuration change, not a rebuild.

    Integrations
  4. 04

    Govern

    Continuous assurance. Append-only ledgers, hash-chained audit events, write-once evidence for binding decisions, dual control on privileged actions, and the operational reads a regulator or correspondent bank asks for.

    Assurance
How to read this page

A capability register, not a feature list.

Across the operating portal, capabilities stand at 4 operational, 9 staged and 12 on the roadmap. Those states are extracted from the product's own module definitions when this site is built, so this page cannot describe something as live that the platform records as staged. A capability marked Staged has its controls and data boundaries defined but is not yet connected; one marked On the roadmap is committed but not built. We would rather you diligence this from the page than from a call.

Operate

Running the business day to day.

Overview and analytics

Operational

A permission-aware view of the operating surfaces available to this exact workspace.

CapabilityWhat it doesState
Role workspaceReturn to the operational queue and controls assigned by the server.Operational
Hub snapshotPayment performance, balances, alerts and corridor health will appear after authoritative aggregate APIs are delivered.Staged
Tasks requiring attentionA unified task inbox is planned; current queues remain separated by operational authority.On the roadmap

Transactions and payments

Operational

Monitor server-authorised payments and enter supported transfers without bypassing rail, ledger or approval gates.

CapabilityWhat it doesState
Transaction registerSearch and inspect transactions returned for the current agent or entity boundary.Operational
Single transferCreate a quote-backed transfer request only when the deployment has a connected actor directory; authorisation remains a separate API step.Operational
Batch payoutsFile validation, duplicate detection, quote handling and approval orchestration are not connected in this release.Staged
Beneficiaries and schedulesReusable beneficiaries, recurring payments and scheduled instructions remain a planned server capability.On the roadmap

Compliance and risk

Operational

Access the assigned compliance queue while keeping internal risk logic and elevated decisions compartmentalised.

CapabilityWhat it doesState
Assigned case queueOpen the current analyst or MLRO queue under the same role, assignment and action gates.Operational
Monitoring and screeningSanctions, PEP, AML and velocity services remain server-owned; their internal rules are not reproduced here.Staged
Evidence and disputesSecure document collection, malware scanning and dispute workflows are planned integrations.On the roadmap

Treasury and liquidity

Staged

A staged back-office view for reconciled balances, funding readiness, FX and liquidity controls.

CapabilityWhat it doesState
Multi-currency balancesAvailable, pending, reserved and projected views await ledger-backed balance APIs.Staged
Funding and FXFunding instructions, incoming funds, conversions and rate locks are not executable here.Staged
Sweeping and forecastingThreshold rules, rebalancing and short-term liquidity forecasts are planned for a later control phase.On the roadmap
Connect

Reaching the rails and the vendors.

Network and corridors

Staged

A staged home for corridor rules, delivery methods, cut-offs, limits, fees and operational status.

CapabilityWhat it doesState
Corridor explorerSearchable country, currency, identifier and delivery-method coverage is awaiting a versioned network API.Staged
Fees and FX availabilityIndicative matrices and quote-time validation will remain visibly distinct when connected.Staged
Cut-offs and rail healthBank holidays, operating windows and degraded rails require near-real-time provider inputs.On the roadmap

Merchant collections

On the roadmap

Planned collection channels, settlement, refunds and reconciliation for supported merchant programs.

CapabilityWhat it doesState
Collection channelsCards, bank transfers, direct debit, QR and wallet acceptance require provider and product approval.On the roadmap
Payment links and invoicesHosted links, invoices and checkout configuration remain outside the current release.On the roadmap
Settlements and refundsNet settlement, matching, disputes and refunds require ledger-backed workflows and approvals.On the roadmap

Developer and API

On the roadmap

Planned sandbox, credential, webhook and diagnostic tooling for explicitly entitled integration teams.

CapabilityWhat it doesState
API credentialsScoped key issuance, one-time secret display, rotation and revocation require dedicated server entitlements.On the roadmap
Webhooks and logsSigned delivery configuration, request logs and replay controls are awaiting audited backend services.On the roadmap
Sandbox and simulatorCorridor and error simulation will be isolated from production identities and money movement.On the roadmap

Provider integrations that are live today — payout rails, screening, identity, messaging — are listed on Connections.

Govern

Administration, authority and evidence.

Organisation and administration

Staged

A staged main-agent administration surface for delegated users, entities, policies and immutable audit evidence.

CapabilityWhat it doesState
Users and teamsInvitations, team membership and delegated access are awaiting explicit administration endpoints.Staged
Roles and approval policiesCustom roles, thresholds and multi-level approval configuration require validated policy workflows.Staged
Security and auditSession history, notification preferences and audit search will follow dedicated least-privilege grants.On the roadmap

The record-keeping controls beneath these surfaces — append-only ledgers, write-once evidence, dual control — are described on Governance.

Beyond the portal

Capabilities that live in the platform, not on a screen.

The register above tracks the operator portal — what a person can do in a browser. A good deal of the platform is reached through the API and enforced in the schema, where there is no screen to mark Operational. Those capabilities are listed here separately rather than folded in, because a register that quietly mixed the two would be a register you could not trust.

CapabilityWhat it doesWhere it lives
Corridor Net Settlement Agreed daily cutoffs with an explicit timezone, obligations bound to a cycle when attributed, and a closed cycle that refuses new assignments. Clearing
Netting groups Set-off permitted only while an agreement signed by every member and the counterparty is in force. Netting stops at the treasury that holds the account. Clearing
Corridor credit Facilities, headroom and reservations checked and taken in one locked operation before a quote exists, against the net due to the rail. Clearing
Agreement chain verification Recomputes the record chain, names the first entry that does not follow, and reports how many entries have accrued since a head was last published externally. Governance
Payout provider registry Partners are data rather than a compiled-in list. Adding one is a record; a partner that carried payouts is retired by status, never erased. Connections
Brands and operators One trading name across many licensees, with the operating entity always visible, and separate authority to admit a member versus remove one. API
Ownership groups Owners see the commercials of the licensees they own, and never another operator's customers. API
KYB requirement packs Per-jurisdiction corporate requirements that decide the outcome rather than describe it, including acting as an agent of a principal across borders. API
Customer standing Customer KYC standing carried explicitly, including the outcome between accepted and refused that a two-state model has to pretend does not exist. API
Order lifecycle The recipient the customer confirmed is bound to the order, a receipt is issued, money is collected before the price is frozen, and cancellation and refund are controlled operations. API
Pricing authority What a corridor costs is kept separate from what the customer is charged, so a margin is a decision rather than a side effect. Pricing
Sealed fiat boundary The platform holds no fiat and issues no bank instruction. The boundary is enforced in the schema, not by policy. Clearing
Launch

What the first ninety days look like.

Launch is an engagement rather than a module, so it has no delivery state to publish. It is scoped against the permissions your entity holds and the corridors you intend to serve.

Configure

Entity and agent hierarchy, compliance thresholds, approval policy, branding and user roles, set to your licence rather than to a default.

Integrate

Credentials scoped to your permissions, corridor enablement, first transactions in a controlled environment, and operator training.

See it against your own corridors.

A demo runs on the capabilities marked operational above — not on a prototype. Tell us the entity you operate as and we will scope it to that.