QUANTVESTRIX INC · v1.0 · 2026-10-05

ISO 20022, for a dollar carried inside the coin.

QUSD is a fully-backed 1:1 US-dollar stablecoin: every coin carries its own dollar of fiat inside its mint ByteID and reads on chain. This manual shows how QUSD maps onto the ISO 20022 payment standard — pain, pacs and camt messages — and what that means for each kind of user, from an individual holder to a settlement bank.

Peg $1.00 · par · redeemable 1:1

Overview

ISO 20022 is the international standard for electronic payment messaging between customers, businesses and financial institutions. QUSD speaks it so that minting, sending, settling and reporting a QUSD dollar look to a bank exactly like a standards-based payment — while the backing stays provable on chain, without trusting anyone.

One standard, one dollar

Every QUSD is one dollar. An ISO 20022 instruction for QUSD carries the same amount, currency, parties, reference and UETR a bank already expects — the coin is the settlement asset.

Backing in the coin

A QUSD is never issued past its backing: the dollar is folded into the coin's own mint ByteID at issuance. Coverage is 1.0000 by construction — there is no pool to drain and nothing to misreport.

Verify without us

Supply reads from chain with totalSupply(); backing reads with committedValue(bytes8); any figure re-folds at /reflect. No account, no key, no bank to call.

QUSD is live across six chains — QVTX 42000, Polygon, BSC, Base, Arbitrum and the XRP Ledger — so you can settle where your counterparty already is, without a third-party bridge's IOU. See the live register on qusd.us and qusdscan.us.

Full ISO 20022 message list

Every ISO 20022 message type QUSD is XSD-gated for — 18 message types across 27 schema versions, each validated against its .xsd on disk before anything is built or accepted. Search or filter by family. live marks what the gateway advertises at /iso20022 today.

Message	Schema versions	Name	Direction	Used for
pain.001 live	.001.03 · .001.09 · .001.11	CustomerCreditTransferInitiation	Customer → bank	Initiate a credit transfer — the instruction that funds a QUSD mint or a payout.
pain.002	.001.03 · .001.10 · .001.12	CustomerPaymentStatusReport	Bank → customer	Status of a pain.001 across its lifecycle (`ACTC`…`ACSC`/`RJCT`).
pacs.008 live	.001.08 · .001.10	FIToFICustomerCreditTransfer	Bank → bank	Interbank customer credit transfer — the settlement leg; the correct message for a corporate debtor.
pacs.009 live	.001.10	FinancialInstitutionCreditTransfer	Bank → bank	FI own-account transfer. Not interchangeable with pacs.008.
pacs.002	.001.10 · .001.12	FIToFIPaymentStatusReport	Bank → bank	Interbank payment status report.
pacs.004	.001.09	PaymentReturn	Bank → bank	Return of a previously settled credit.
camt.053	.001.02 · .001.08 · .001.10	BankToCustomerStatement	Bank → customer	End-of-day statement — the artefact that closes reconciliation; binds to a ByteID via the mint spec.
camt.054	.001.08 · .001.10	BankToCustomerDebitCreditNotification	Bank → customer	Per-entry debit/credit notification — "a dollar landed."
camt.050	.001.05	LiquidityCreditTransfer	Bank → bank	Liquidity transfer (credit).
camt.051	.001.05	LiquidityDebitTransfer	Bank → bank	Liquidity transfer (debit).
camt.003	.001.07	GetAccount	Customer → bank	Query account information.
camt.004	.001.08	ReturnAccount	Bank → customer	Account information report.
camt.009	.001.07	GetLimit	Customer → bank	Query a limit.
camt.010	.001.08	ReturnLimit	Bank → customer	Limit report.
acmt.001	.001.08	AccountOpeningInstruction	Customer → bank	Open an account.
acmt.002	.001.08	AccountDetailsConfirmation	Bank → customer	Confirm account details.
acmt.003	.001.08	AccountModificationInstruction	Customer → bank	Modify an account.
head.001	.001.02	BusinessApplicationHeader	Envelope	Wraps a business message for routing and signing.

Every version here has its .xsd on disk and is enforced by the schema gate — a message that does not validate is rejected before it is built or accepted. Identifiers every message carries: a UETR (UUID v4, one per instruction, never reused), an EndToEndId (≤ 35 chars, constant across a logical batch), and unstructured remittance (RmtInf, ≤ 140 chars). Structured creditor addresses become mandatory from November 2026.

QUSD ↔ ISO 20022

Each QUSD action has an ISO 20022 counterpart. The coin is the settlement asset; the messages describe its movement in the language banks already use.

Mint QUSD (deposit a dollar, coin issued)

→

pain.001 initiation · dollar folded into the mint ByteID

Status of that mint / payment

→

pain.002 (ACTC → ACCP → ACSP → ACSC)

Transfer / settle between institutions

→

pacs.008 FIToFICustomerCreditTransfer

"A dollar landed" notification

→

camt.054 credit notification

End-of-day statement

→

camt.053 statement

Redeem QUSD (1:1, at par)

→

pain.001 payout · burn against backing

Prove the backing

→

on-chain committedValue(bytes8) · /reflect re-fold

User type

Individuals & holders

You hold QUSD in your own wallet — non-custodial, its dollar carried inside the coin, not on anyone's balance sheet and not freezable on a platform. You can mint your own, hold it, send it, and redeem it 1:1.

Mint your own dollar

Deposit a dollar; a QUSD is issued with that dollar folded into its ByteID. In ISO terms your deposit is a pain.001 credit-transfer initiation; the coin is the result. Mint at qusd.us/mint.

Hold a real NFT dollar

QUSD$ is an on-chain NFT dollar — unique, owned, transferable, backed 1:1. It renders anywhere a wallet opens a link (PNG / SVG / JSON).

Up, never down

A hard floor at par: QUSD is redeemable 1:1 and is never sold below $1.00. Redemption is a pain.001 payout against the coin's own backing.

How a mint flows

Connect a wallet to QVTX chain 42000 (the Connect button on qusd.us adds the network for you).

Initiate the dollar in — this is your pain.001. The coin is minted with the dollar committed in the same act, so it can never be issued past its backing.

Receive the coin and a credit notification (camt.054 equivalent). The coin is yours, in your wallet.

Verify it yourself on qusdscan.us — look up the coin, its ByteID and its backing, straight from chain.

You never have to trust a custodian or a quarterly attestation. Every coin's dollar is in its own ByteID and reads on chain, any time, with no permission from anyone.

User type

Merchants & business

Accept QUSD for goods and services and settle 1:1, with every payment reconcilable by the references ISO 20022 already defines. One dollar in equals one dollar settled — no slippage, no depeg from a thin pool.

Invoice → EndToEndId

Put your invoice or order number in the EndToEndId (≤35 chars) and keep it constant across the batch. It survives end to end, so a payment reconciles to an invoice automatically.

Receive & reconcile

Incoming settlement arrives as a pacs.008 credit; you reconcile against a camt.054 per-credit notification and a camt.053 end-of-day statement — matched on UETR and amount.

Payouts

Pay suppliers or staff in QUSD by issuing a pain.001 with their address as creditor. Returns, if any, come back as pacs.004 / camt.056.

Reconciliation discipline

One EndToEndId per logical batch; a fresh UETR per instruction. Never reuse a UETR.

Match on UETR and amount, not on a running balance. Confirm each credit independently.

Close the day on the statement. A sum of confirmed credits is not a balance — the camt.053 statement is what establishes the position.

User type

Banks & financial institutions

QUSD settles institution-to-institution over a standards-based rail. The outbound settlement message is pacs.008; delivery is an HMAC-signed, idempotent instruction; reconciliation closes on camt.053.

pacs.008 is the message

Where the debtor is a corporate (not a financial institution), the interbank credit transfer is pacs.008, carrying debtor, creditor, amount, currency, UETR and remittance. pacs.009 is for an FI's own-account transfer and is not interchangeable.

Idempotent by content

Delivery is keyed on (partnerId, byteId) and on UETR. Because the byteId is derived from the instruction's content, a byte-identical retry cannot double-credit. A changed amount, reference or UETR is a new instruction, not a retry.

Authorised, per instruction

Posting real credit to a core requires the explicit, current authorisation of the sending institution for that specific instruction. Standing approval does not carry to a later instruction.

Currency & FX

A settlement rail settles in its stated currency; where a currency conversion is needed it is agreed and stated on the instruction, with the rate basis recorded. A minted balance is never presented as settlement cover.

Delivery & reconciliation

Check liveness and limits before a run; confirm settlement currency and account.

One connection per instruction; do not pipeline. Pace instructions, and capture the complete response body — it is the receipt.

Re-read every instruction independently after submit — a submit acknowledgement is not settlement. Confirm status ACSC/ posted and that ledger id, reference, UETR and byteId are distinct across legs.

Reconcile on ledger id and amount, and close on the camt.053 statement. Never present a sum of postings as a balance.

Structural acceptance is not settlement. A network/technical acceptance (ACTC) means the envelope validated — not that funds settled (ACSC). Treat the two as different states, always.

User type

Developers & integrators

Build against open, keyless endpoints and on-chain reads — the same ones qusd.us and qusdscan.us use. No key, no account.

Live endpoints

Method	Endpoint	Returns
GET	qusd.us/iso20022	ISO 20022 capability — enabled messages and rails.
GET	qusd.us/byteid	The ByteID sovereign-transport protocol card and types.
POST	qusd.us/reflect	Fold any payload → its sense and shadow ByteID, with an involution check.
RPC	qusd.quantvestrix.io/_rpc/42000	JSON-RPC to QVTX chain 42000 (also `/_rpc/20232`).

On-chain reads (no endpoint required)

Call	Where	Returns
totalSupply()	each QUSD contract, any of the six chains	Minted supply at 18 decimals.
balanceOf(addr)	each QUSD contract	Circulating vs treasury-held.
committedValue(bytes8) sel 0x4058baa5	anchor registry, chain 42000	Dollars committed to a backing ByteID.

Identifiers & rules

UETR	RFC 4122 v4 UUID, lowercase, one per instruction, never reused.
MsgId	`QVTX-YYYYMMDDHHMMSS-XXXXXXXX`, unique per message.
EndToEndId	≤ 35 chars, assigned by the originator, constant across a logical batch.
RmtInf (Ustrd)	≤ 140 chars unstructured remittance.

Sample — read capability and fold a value

# what ISO 20022 messages are enabled
curl -s https://qusd.us/iso20022

# fold any payload; confirm the engine lands on your sense + shadow ByteID
curl -s -X POST https://qusd.us/reflect \
  -H 'content-type: application/json' \
  -d '{"amount":"1500.00","ccy":"USD","ref":"Invoice #12345"}'

Idempotency is content-derived: send a byte-identical instruction twice and it cannot double-apply. Change any field and it is a new instruction. Build retries around exact-bytes resends.

User type

Auditors & regulators

QUSD is built to be checked, not trusted. Every figure can be reproduced from primary sources — the chain and a keyless fold — with no cooperation from the issuer.

Read supply from chain. Call totalSupply() on each QUSD contract across the six chains and sum at 18 decimals. Compare to the published register on qusd.us — derive it, don't take it.

Read backing from chain. committedValue(bytes8) on chain 42000 returns the dollars committed to a backing ByteID. Coverage is 1.0000 by construction, measured per coin — not a single pooled reserve ratio.

Re-fold any figure at /reflect and confirm the engine lands on the same sense and shadow ByteID as yours. A mismatch is a finding, not a support ticket.

Browse it on qusdscan.us — contracts, tokens, transfers and charts, read straight from chain.

Dual-channel verification: each attested backing record re-folds to exactly its recorded identifier across two independent channels — software and silicon. The attestation is a computation that reproduces on demand, not a signed PDF.

Status & reject codes

Transaction status (pain.002)

Code	Name	Meaning
ACTC	AcceptedTechnicalValidation	Syntax/schema valid. Not settlement.
ACCP	AcceptedCustomerProfile	Business rules passed.
ACSP	AcceptedSettlementInProcess	Settlement in progress.
ACSC	AcceptedSettlementCompleted	Final — settled.
ACWC	AcceptedWithChange	Accepted with modifications.
PART	PartiallyAccepted	Some transactions accepted.
PDNG	Pending	Awaiting processing.
RCVD	Received	Received, not yet processed.
RJCT	Rejected	Rejected — see reason code.

Common reject reasons

Code	Name	Meaning
AC01	IncorrectAccountNumber	Account not found.
AC04	ClosedAccountNumber	Account closed.
AC06	BlockedAccount	Account blocked.
AM01	ZeroAmount	Amount is zero.
AM02	NotAllowedAmount	Amount exceeds a limit.
AM04	InsufficientFunds	Balance does not cover the amount.
AM09	WrongAmount	Amount does not match.
BE04	MissingCreditorAddress	Structured address required.
MD01	NoMandate	No authorisation.
RC01	BankIdentifierIncorrect	Invalid routing/BIC.
RR01	MissingDebtorAccount	Debtor account not specified.
RR04	RegulatoryReason	Compliance rejection.

XML templates

pain.001 — customer credit transfer initiation

<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.001.09">
  <CstmrCdtTrfInitn>
    <GrpHdr>
      <MsgId>QVTX-20261005103000-A1B2C3D4</MsgId>
      <CreDtTm>2026-10-05T10:30:00</CreDtTm>
      <NbOfTxs>1</NbOfTxs>
      <CtrlSum>1500.00</CtrlSum>
      <InitgPty><Nm>QUANTVESTRIX INC</Nm></InitgPty>
    </GrpHdr>
    <PmtInf>
      <PmtInfId>PMT-TRF-20261005-001</PmtInfId>
      <PmtMtd>TRF</PmtMtd>
      <ReqdExctnDt>2026-10-05</ReqdExctnDt>
      <Dbtr><Nm>QUANTVESTRIX INC</Nm></Dbtr>
      <CdtTrfTxInf>
        <PmtId><EndToEndId>Invoice-12345</EndToEndId>
          <UETR>e00b5ba0-5c1e-4c8a-9c3d-7f2a1b3c4d5e</UETR></PmtId>
        <Amt><InstdAmt Ccy="USD">1500.00</InstdAmt></Amt>
        <Cdtr><Nm>John Smith</Nm></Cdtr>
        <RmtInf><Ustrd>Invoice #12345</Ustrd></RmtInf>
      </CdtTrfTxInf>
    </PmtInf>
  </CstmrCdtTrfInitn>
</Document>

pacs.008 — FI-to-FI customer credit transfer

<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pacs.008.001.08">
  <FIToFICstmrCdtTrf>
    <GrpHdr>
      <MsgId>PACS-20261005103100-C3D4E5F6</MsgId>
      <CreDtTm>2026-10-05T10:31:00</CreDtTm>
      <NbOfTxs>1</NbOfTxs>
      <SttlmInf><SttlmMtd>CLRG</SttlmMtd></SttlmInf>
    </GrpHdr>
    <CdtTrfTxInf>
      <PmtId><UETR>e00b5ba0-5c1e-4c8a-9c3d-7f2a1b3c4d5e</UETR></PmtId>
      <IntrBkSttlmAmt Ccy="USD">1500.00</IntrBkSttlmAmt>
    </CdtTrfTxInf>
  </FIToFICstmrCdtTrf>
</Document>

camt.054 — credit notification

<Document xmlns="urn:iso:std:iso:20022:tech:xsd:camt.054.001.08">
  <BkToCstmrDbtCdtNtfctn>
    <Ntfctn>
      <Ntry>
        <Amt Ccy="USD">1500.00</Amt>
        <CdtDbtInd>CRDT</CdtDbtInd>
        <Sts>BOOK</Sts>
        <NtryDtls><TxDtls><Refs>
          <UETR>e00b5ba0-5c1e-4c8a-9c3d-7f2a1b3c4d5e</UETR>
        </Refs></TxDtls></NtryDtls>
      </Ntry>
    </Ntfctn>
  </BkToCstmrDbtCdtNtfctn>
</Document>

Glossary

ByteID	The quaternary fold of a coin's content and its backing. A QUSD's dollar is carried inside its mint ByteID; it re-folds to exactly its recorded identifier.
committedValue	On-chain read (`bytes8` → dollars) that returns the backing committed to an anchor ByteID on chain 42000.
UETR	Unique End-to-end Transaction Reference — a UUID v4 that tracks one instruction across every institution.
EndToEndId	Originator-assigned reference (≤35 chars) that survives end to end — ideal for an invoice or order number.
pain / pacs / camt	ISO 20022 families: customer-to-bank initiation / bank-to-bank clearing & settlement / bank-to-customer cash management (reporting).
Par	$1.00. QUSD is issued and redeemed at par; the peg holds or rises, never breaks downward.
BIC	Bank Identifier Code (SWIFT). Used to route interbank messages; a code that is not a live, registered SWIFT connection is never placed in an envelope as one.