Solana ↔ ISO 20022 — FAQ

A Solana transaction signature is 88 characters long (base58-encoded). However, the ISO 20022 schema enforces a maximum of 35 characters for most identifier fields, including MsgId, AcctSvcrRef, and EndToEndId. This is a hard constraint in the XSD — any value longer than 35 characters would make the XML invalid.

ISOFIX truncates to the first 35 characters rather than hashing because:

• The first 35 characters of a base58 signature already have extremely low collision probability — base58 gives ~5.86 bits of entropy per character, so 35 chars ≈ 205 bits.
• Truncation preserves a prefix that can be searched on block explorers (paste the 35 chars into Solscan and it will find the transaction).
• A hash would be opaque — you couldn't trace it back to the on-chain transaction without a lookup table.

In traditional banking, these are two different references: the bank assigns its own reference (AcctSvcrRef — the account servicer's reference), while the originator's reference (EndToEndId) travels from sender to receiver.

On Solana, there is no bank assigning a separate reference. The transaction signature is the universal identifier — it serves as both the "bank's reference" and the "end-to-end reference." That's why ISOFIX uses the same value for both fields.

This is actually more transparent than traditional banking: one immutable, publicly verifiable reference instead of two separate IDs in different systems.

GrpHdr/MsgId is the message identifier — it identifies the camt.053 file itself, not any individual transaction. A single camt.053 can contain dozens or hundreds of transactions, so it can't be a single Solana signature.

ISOFIX generates this as a synthetic ID combining the currency, date, and a timestamp: GBITSCHF202501011710345678. It's unique per generated file. The individual Solana signatures live at the entry level inside Ntry/AcctSvcrRef and NtryDtls/TxDtls/Refs/EndToEndId.

SOLNCHZZXXX is a synthetic BIC (Bank Identifier Code) that ISOFIX uses as the Account Servicer. It's not registered with SWIFT — no one can route a real payment to it. It exists because the ISO 20022 schema requires a BICFI element in the Acct/Svcr/FinInstnId block, and it must follow the valid BIC format.

Breaking it down following the SWIFT structure:

The CH country code positions the report in a Swiss context, which matters for SPS compliance and Bexio import. For a US-focused deployment, you might use SOLNUS33XXX instead.

By default, ISOFIX uses the Solana wallet address (e.g., JBL2idfXZJpsaErVMYRut8fDdwXntJD7fUNJpnaUCmS6) as the Acct/Ownr/Nm because that's the only on-chain identity available. Solana has no built-in name registry for wallet addresses.

Since v2025.03, ISOFIX provides an optional "Account Owner" field in the UI (Step 4) where you can enter a human-readable name and a structured CBPR+ postal address. When filled in, the generated XML includes:

Future integrations with swiyu E-ID or vLEI could populate this automatically from cryptographically attested identity credentials.

The IBAN field exists to link the generated statement to a specific bank account in your ERP (e.g., Bexio). When you import a camt.053, Bexio matches it to a bank account by IBAN. Without an IBAN, the import may fail or require manual assignment.

If you leave the IBAN empty, ISOFIX falls back to placing the Solana wallet address in Acct/Id/Othr/Id instead of Acct/Id/IBAN. This is schema-compliant but may not be recognized by all ERP systems.

The OPBD (Opening Booked Balance) represents the account balance at the start of the statement period. A real bank carries this over from the previous statement's closing balance.

ISOFIX doesn't carry state between statements — it has no record of your previous closing balance. Querying the historical token balance at a specific Solana slot is technically possible but most RPC providers don't retain this data affordably.

For Bexio import, this works fine — Bexio uses the individual entries and the closing balance, and doesn't cross-check the opening balance against a previous statement. But it's a known simplification.

These are the ISO 20022 Bank Transaction Codes that classify each entry. They tell the ERP what kind of transaction this is:

ISOFIX automatically selects ICDT for outgoing (DBIT) and RCDT for incoming (CRDT) transactions. The ESCT sub-family is used because Swiss accounting software expects SEPA-style transaction codes for domestic and European payments.

In traditional banking, the booking date (BookgDt) is when the transaction was recorded by the bank, and the value date (ValDt) is when the money was effectively transferred. These can differ by days (e.g., T+1 or T+2 settlement).

On Solana, settlement is instant — when a transaction is confirmed in a block, it's immediately final. There is no settlement delay. So both dates use the block timestamp, and they're always identical.

This is actually an advantage: Solana's instant finality means no ambiguity about when a payment "really" happened.

RvslInd (Reversal Indicator) marks whether a transaction is a reversal of a previous one. In banking, a payment can be recalled or reversed under certain conditions (e.g., SEPA Direct Debit reversals).

On Solana, transactions are irreversible by design. Once a block is confirmed, it cannot be undone. There is no chargeback, no recall, no reversal mechanism at the protocol level. So this flag is always false.

When a payment is made via Gbits Pay against a Swiss QR invoice, the QR reference is embedded in the Solana transaction's SPL Memo with a QRR: prefix (e.g., QRR:210000000003139471430009017).

ISOFIX detects this prefix and maps it to the structured remittance information block:

This is the standard location where Swiss ERP systems (Bexio, SAP, Abacus) look for the QR reference. When the camt.053 is imported, the ERP automatically matches the payment to the open invoice via this reference — no manual reconciliation needed.

When the memo doesn't start with QRR:, ISOFIX falls back to unstructured remittance information:

This concatenates the stablecoin label (e.g., SOL-VCHF) with the full Solana transaction signature, providing a provenance trail even without a structured reference. The field is capped at 140 characters per the schema.

Each stablecoin has a unique SPL token mint address on Solana. ISOFIX maintains a mapping from mint address to ISO 4217 currency code:

Multiple stablecoins with the same currency are grouped into a single camt.053 report. For example, USDC and USDT transactions both appear in the USD report.

ISOFIX generates one camt.053 per currency. If your wallet has both USDC (USD) and VCHF (CHF) transactions in the selected period, you'll get two files: camt053_USD_... and camt053_CHF_....

This matches how traditional banks work — a CHF bank account produces a CHF statement, a USD account produces a USD statement. Each camt.053 has a single Ccy in its Acct block.

The BAI2 format works differently — it combines all currencies into one file.

ISOFIX uses Solana Name Service (SNS) subdomain lookups via the verified-iban.sol domain. Each verified IBAN is registered as a subdomain:

The verified-iban.sol domain is owned by the project. IBAN subdomains are registered manually after the wallet owner verifies their IBAN ownership. This is a trust bottleneck in the current design — a future version could use swiyu E-ID or bank-issued verifiable credentials to automate the verification.

Bexio import has been validated for camt.053 and camt.054 (February 2026), including duplicate detection across message types.

This is the Swiss Payment Standards version identifier. It tells the receiving system which SPS version the file conforms to:

• SPS/1.7/PROD — used in camt.053, meaning SPS version 1.7, production mode
• SPS/2.1/PROD — used in camt.054, meaning SPS version 2.1 (the 2024 update with structured status codes and datetime booking dates)

Swiss banks and ERP systems use this to apply the correct parsing rules. The PROD suffix distinguishes production from test files (TEST).

The generated XML validates against the official ISO 20022 XSD schemas. The Swiss Payment Standards compliance is followed for camt.053 (SPS 1.7), camt.054 (SPS 2.1), and pain.001 (SPS 2009 Swiss flavor). Import into Bexio has been tested successfully.

However, "compliance" is not a binary property. Some fields use synthetic values (SOLNCHZZXXX as BIC, wallet addresses as counterparty names) that are schema-valid but unconventional. A strict compliance audit by a Swiss bank would likely flag these as non-standard, which is expected — ISOFIX is translating between two fundamentally different financial systems.

For outgoing payments, RltdPties/Cdtr/Nm shows the recipient's Solana wallet address. For incoming payments, RltdPties/Dbtr/Nm shows the sender's address. This is because Solana addresses are pseudonymous — there's no on-chain mapping from address to human name.

In the future, this could be enriched via:

• SNS reverse lookup — if the counterparty has a .sol domain, use it as the name
• swiyu E-ID — if the counterparty has a verified identity, display their legal name
• Company address book — a local mapping maintained by the user

For now, the address is functional if not pretty — and it's always verifiable on-chain.