Request & message
Capture the instruction, validate its details and run required checks before a message can move.
Planned ISO 20022 scope
pain.001 · pacs.008 · pacs.002 · pacs.004
Cross-border payment coordination
Know the request.
Track each step.
Cross-border payment coordination with clear workflow records.
Bricspay coordinates local-currency payment requests while keeping payment instructions, workflow evidence and settlement status distinct.
01 MVP scope: simulated accounts, currencies and workflows.
The operating model
Three layers.
One clear record.
Each part has a distinct job. A recorded event never stands in for money actually settling.
Transaction coordination
Record decisions, approvals and status changes in an auditable workflow. Keep identity and invoice data off public blockchains.
Reviewable events
Incomplete or flagged requests are held.
Settlement simulation
Model account balances, local-currency quotes, liquidity and payment-versus-payment scenarios in a separate test layer.
Simulation only
No bank, RTGS or CBDC connection is active.
A workflow ledger is evidence of recorded events, not proof of final settlement.
A traceable sequence
A message moves.
Settlement has its own status.
Requests move through separate checkpoints. Reviews can pause a request; returns and refusals remain distinct outcomes.
Ask about the test workflowOpen the example form- 01
Request submitted
An instruction is created with a purpose, beneficiary and supporting details.
- 02REVIEW GATE
Review in progress
Identity, authority and compliance checks can hold incomplete or flagged requests.
- 03
Message sent
A validated payment message moves to the counterparty. It is not a settlement event.
- 04
Counterparty accepted
Acceptance is recorded as its own auditable status.
- 05SIMULATED
Test settlement confirmed
The simulator can record a test result against simulated accounts and currencies.
- 06
Beneficiary credited
A separate simulated event completes the test workflow.
Designed for shared oversight
One workflow.
Different responsibilities.
Financial institutions
Review organizational membership, delegate approval roles and follow messages and test liquidity in a controlled environment.
Businesses
Prepare a payment request with beneficiary and invoice details, then route it through the right internal approvals.
Individuals
Review a test fee and indicative quote before signing a request. A wallet verifies control; it never grants access to bank or CBDC systems.
Trust is part of the workflow
Control before
the next step.
Payment requests should be accountable to the people, organizations and rules behind them.
Checks can stop a request
KYC/KYB, beneficial ownership, AML/CFT screening, transaction limits and source-of-funds review are planned gates. A critical check failure holds the request for review.
Wallets verify; they do not custody
Signing is designed around a one-time nonce and expiry. Private keys are never requested or stored, and a signature does not move assets.
Sensitive records stay private
Identity documents and invoices stay off public chains. Authorized roles see only the information their work requires.
Real connections require real activation
Bank, RTGS or wholesale CBDC integrations would need counterparties, agreements, approvals and technical activation first.
A few important distinctions
Clear by design.
Does Bricspay move real money today?
No. This test environment uses simulated accounts, currencies and workflows. It does not initiate transfers, hold balances or settle payments.
Is Bricspay an official BRICS network?
No. Bricspay is independently branded and does not claim official BRICS status or affiliation.
What happens after the test MVP?
Real settlement adapters would be considered only when counterparties, agreements, regulatory approvals and technical activation are in place. Research into a local-currency basket unit of account would remain separate from any token issuance.