OpenChainGraph v0.3 introduces an optional, additive ISO 20022-aligned semantic overlay for the financial payload of OCG decision-chain artifacts. This guide covers the overlay's field mapping, the published iso20022-context.jsonld, client-side validation of the five external code lists (ISO 4217, 3166, 9362, 13616, 17442), crosswalk to pacs.008 for interoperability, and the ocg:semantic_profile discovery marker for graph-index crawlers. The hash preimage is unchanged from v0.1.
OpenChainGraph v0.2 gave the provenance envelope a semantic standard: W3C PROV-DM terms such as wasGeneratedBy and wasAttributedTo describe who ran what and when. OpenChainGraph v0.3 gives the financial payload a semantic standard: an ISO 20022-aligned vocabulary that names payload fields after the corresponding ISO 20022 business elements.
The overlay is opt-in, additive, and minimal. You adopt it by extending the artifact's @context array with the published overlay URL. No existing fields are removed or renamed. Tools that do not include the overlay remain valid v0.3 artifacts. Tools that do include it gain machine-readable alignment to ISO 20022 terminology for interoperability with financial messaging infrastructure.
OCG is ISO 20022-aligned, not a registered ISO 20022 message. ISO 20022 message definitions are published and governed by the ISO Registration Authority (ISO/TC68) and administered operationally by SWIFT. OpenChainGraph does not register message types with the ISO RA, does not generate ISO 20022 XML or MX messages, and is not a conformant ISO 20022 implementation. The alignment is a semantic crosswalk for interoperability, the same relationship as JSON-LD vocabularies that name their terms after W3C concepts without being W3C specifications.
{
"@context": [
"https://ainumbers.co/chaingraph/context/v0.3/context.jsonld",
"https://ainumbers.co/chaingraph/context/v0.3/iso20022-context.jsonld" /* v0.3 overlay */
],
"ocg:semantic_profile": "iso20022:pacs.008-subset", /* discovery marker */
"tool_id": "T290",
"tool_version": "1.0.0",
"ap2_version": "v0.3",
"mandate_type": "settlement_mandate",
"generated_at": "2026-06-18T14:22:00Z",
"execution_hash": "a3f7e2c1d9b04856f31a2e7c5d8b09f6e14c2a3d7b05894e2f1c6a8d3e09b47",
"parent_hashes": ["c8d12f9e3a74b056e28f3c1a5d9e07b2f46a1c8d3e05792b1f4c7a9e2d08b35"],
"output_payload": {
/* ISO 20022 InstructedAmount — amount + currency (ISO 4217) */
"instructed_amount": {
"amount": "15000.00", /* ActiveCurrencyAndAmount */
"currency": "EUR" /* Ccy / CurrencyCode — ISO 4217 */
},
/* ISO 20022 Debtor — PartyIdentification */
"debtor": {
"party_name": "Acme Payments GmbH", /* Nm */
"lei": "549300TRUWO2CD2G5692", /* OrganisationIdentification/LEI — ISO 17442 */
"country": "DE" /* CountryCode — ISO 3166-1 alpha-2 */
},
/* ISO 20022 Creditor — PartyIdentification */
"creditor": {
"party_name": "Northern Trust Corp", /* Nm */
"lei": "5493008IOANM4MK63B46", /* OrganisationIdentification/LEI — ISO 17442 */
"country": "US" /* CountryCode — ISO 3166-1 alpha-2 */
},
/* ISO 20022 DebtorAgent — BranchAndFinancialInstitutionIdentification */
"debtor_agent": {
"bicfi": "DEUTDEDBFRA" /* BICFI — ISO 9362 */
},
/* ISO 20022 CreditorAgent — BranchAndFinancialInstitutionIdentification */
"creditor_agent": {
"bicfi": "NTRSUS33XXX" /* BICFI — ISO 9362 */
},
"settlement_date": "2026-06-20", /* IntrBkSttlmDt — ISO 8601 date */
"remittance_information": "INV-2026-00847" /* RmtInf */
},
"compliance_flags": [
{ "framework": "CBPR+", "status": "PASS" },
{ "framework": "LEI_VALID", "status": "PASS" }
],
"audit_signature": {
"zero_pii_verified": true,
"signatures": [{
"keyid": "ocg-signer-v1",
"sig": "base64url-ed25519-signature-here"
}]
}
}
The v0.3 ISO 20022 overlay is additive metadata only. The execution_hash preimage remains exactly as defined in v0.1: a deterministic SHA-256 over the sorted-key JSON of {"policy_parameters": …, "output_payload": …}. The overlay fields (@context array extension, ocg:semantic_profile) are outside the preimage. Adding or removing the overlay does not change the hash of an otherwise identical artifact. Verifiers that compute and check execution_hash require no changes.
The complete field-level mapping for the v0.3 ISO 20022 profile. The left column is the OCG payload field name; the center columns identify the corresponding ISO 20022 business element and any external code set adopted by reference. All five code sets are validated client-side in §4.
| OCG field | ISO 20022 business element | External code set | Notes |
|---|---|---|---|
| instructed_amount.amount | ActiveCurrencyAndAmount | – | Decimal string; paired with Ccy attribute (the currency field). |
| instructed_amount.currency | Ccy / CurrencyCode | ISO 4217 | 3-letter uppercase alphabetic code. Adopted by reference, not redefined. |
| debtor.country / creditor.country | CountryCode | ISO 3166-1 alpha-2 | 2-letter uppercase country code. Used in PostalAddress elements. |
| debtor / creditor | Debtor / Creditor (PartyIdentification) | – | Container for Nm, PstlAdr, and Id sub-elements. |
| debtor.party_name / creditor.party_name | Name (Nm) | – | Free-text party name, max 140 chars in ISO 20022 pacs.008. |
| debtor.lei / creditor.lei | OrganisationIdentification/LEI | ISO 17442 | 20-char alphanumeric Legal Entity Identifier. Check-digit verified (§4e). |
| debtor_agent / creditor_agent | DebtorAgent / CreditorAgent (BranchAndFinancialInstitutionIdentification) | – | Container for FinInstnId and BICFI sub-elements. |
| debtor_agent.bicfi / creditor_agent.bicfi | BICFI | ISO 9362 | 8-char or 11-char Business Identifier Code. Regex-validated (§4c). |
| debtor_account.iban / creditor_account.iban | IBAN (CashAccount/Id/IBAN) | ISO 13616 | International Bank Account Number. Mod-97 check-digit verified (§4d). |
| settlement_date | IntrBkSttlmDt (InterbankSettlementDate) | ISO 8601 date | Date-only string, e.g. "2026-06-20". Not a datetime. |
| remittance_information | RmtInf (RemittanceInformation) | – | Structured or unstructured. OCG stores as a string; structured parsing is application-layer. |
The published overlay file at https://ainumbers.co/chaingraph/context/v0.3/iso20022-context.jsonld is a JSON-LD context that maps every OCG ISO 20022-aligned field name to a term in the iso20022: vocabulary namespace. The namespace prefix iso20022: expands to https://ainumbers.co/chaingraph/vocab/iso20022#; it is a crosswalk namespace named after ISO 20022 elements, not an official ISO 20022 namespace. ISO 20022 publishes no official JSON-LD vocabulary; the crosswalk terms are OCG-defined names that mirror the ISO 20022 business element names for semantic interoperability.
External code lists (ISO 4217, 3166-1, 9362, 13616, 17442) are adopted by reference. The context declares their types using XSD primitives (xsd:string, xsd:date) but does not attempt to inline or redefine the code lists themselves. Validation of code-list membership is the responsibility of the consuming application (see §4).
{
"@context": {
"ocg": "https://ainumbers.co/chaingraph/context/v0.3#",
"iso20022": "https://ainumbers.co/chaingraph/vocab/iso20022#",
"xsd": "http://www.w3.org/2001/XMLSchema#",
"instructed_amount": { "@id": "iso20022:InstructedAmount" },
"amount": { "@id": "iso20022:ActiveCurrencyAndAmount" },
"currency": { "@id": "iso20022:CurrencyCode", "@type": "xsd:string" },
"country": { "@id": "iso20022:CountryCode", "@type": "xsd:string" },
"debtor": { "@id": "iso20022:Debtor" },
"creditor": { "@id": "iso20022:Creditor" },
"party_name": { "@id": "iso20022:Name", "@type": "xsd:string" },
"lei": { "@id": "iso20022:LEI", "@type": "xsd:string" },
"debtor_agent": { "@id": "iso20022:DebtorAgent" },
"creditor_agent": { "@id": "iso20022:CreditorAgent" },
"bicfi": { "@id": "iso20022:BICFI", "@type": "xsd:string" },
"iban": { "@id": "iso20022:IBAN", "@type": "xsd:string" },
"settlement_date": { "@id": "iso20022:InterbankSettlementDate", "@type": "xsd:date" },
"remittance_information": { "@id": "iso20022:RemittanceInformation", "@type": "xsd:string" }
}
}
The iso20022: terms are a vocabulary crosswalk: OCG-defined JSON-LD term names chosen to mirror ISO 20022 business element names. This is the same pattern used by Schema.org and many financial ontologies that reference ISO standards without registering with the standards body. ISO 20022 is a registered standard; OCG is not registered with the ISO RA or with SWIFT. The alignment enables interoperability tooling (field mapping, message generation) without asserting conformance to the ISO 20022 normative specification.
The five code sets referenced by the ISO 20022 profile each have a distinct validation algorithm. The functions below are correct, runnable JavaScript, not pseudocode. They can be used client-side in any OCG tool or in a batch validator pipeline.
/** * ISO 4217 — alphabetic currency codes. * Full list: https://www.iso.org/iso-4217-currency-codes.html * Representative set for validation; expand from the ISO 4217 XML publication. */ const ISO_4217 = new Set([ // Major currencies "AED","AUD","BRL","CAD","CHF","CNY","CZK","DKK","EUR", "GBP","HKD","HUF","IDR","ILS","INR","JPY","KRW","MXN", "MYR","NOK","NZD","PHP","PLN","RON","RUB","SAR","SEK", "SGD","THB","TRY","TWD","USD","ZAR", // Additional ISO 4217 codes — extend from full publication as needed "AFN","ALL","AMD","ANG","AOA","ARS","AWG","AZN","BAM", "BBD","BDT","BGN","BHD","BIF","BMD","BND","BOB","BSD", "BTN","BWP","BYN","BZD","CDF","CLP","COP","CRC","CUP", "CVE","DJF","DOP","DZD","EGP","ERN","ETB","FJD","FKP", "GEL","GHS","GIP","GMD","GNF","GTQ","GYD","HNL","HTG", "IQD","IRR","ISK","JMD","JOD","KES","KGS","KHR","KMF", "KPW","KWD","KYD","KZT","LAK","LBP","LKR","LRD","LSL", "LYD","MAD","MDL","MGA","MKD","MMK","MNT","MOP","MRU", "MUR","MVR","MWK","MZN","NAD","NGN","NIO","NPR","OMR", "PAB","PEN","PGK","PKR","PYG","QAR","RSD","RWF","SBD", "SCR","SDG","SHP","SLL","SOS","SRD","SSP","STN","SVC", "SYP","SZL","TJS","TMT","TND","TOP","TTD","TZS","UAH", "UGX","UYU","UZS","VES","VND","VUV","WST","XAF","XCD", "XOF","XPF","YER","ZMW","ZWL" ]); /** * validateISO4217(code) — returns true if code is a known ISO 4217 alphabetic currency code. * Production use: replace/supplement this set with the authoritative ISO 4217 XML publication. */ function validateISO4217(code) { if (typeof code !== "string") return false; const upper = code.trim().toUpperCase(); return /^[A-Z]{3}$/.test(upper) && ISO_4217.has(upper); } // Examples: console.log(validateISO4217("EUR")); // true console.log(validateISO4217("XYZ")); // false — not a valid ISO 4217 code console.log(validateISO4217("usd")); // true — case-normalised
/** * validateISO3166Alpha2(code) * ISO 3166-1 alpha-2 codes are exactly 2 uppercase ASCII letters. * A full membership check requires the ISO 3166 Maintenance Agency publication. * This implementation validates the format constraint; augment with a Set of * valid codes for strict membership validation in regulated contexts. */ function validateISO3166Alpha2(code) { if (typeof code !== "string") return false; return /^[A-Z]{2}$/.test(code.trim().toUpperCase()); } console.log(validateISO3166Alpha2("DE")); // true console.log(validateISO3166Alpha2("US")); // true console.log(validateISO3166Alpha2("ZZZ")); // false — 3 chars console.log(validateISO3166Alpha2("12")); // false — not alpha
/** * validateBICFI(bic) * ISO 9362 Business Identifier Code (BIC / BICFI): * [A-Z]{4} — institution code (4 letters) * [A-Z]{2} — country code (2 letters, ISO 3166-1 alpha-2) * [A-Z0-9]{2} — location code (2 alphanumeric) * ([A-Z0-9]{3})? — optional branch code (3 alphanumeric) * Total: 8 chars (no branch) or 11 chars (with branch). */ const BIC_REGEX = /^[A-Z]{6}[A-Z0-9]{2}([A-Z0-9]{3})?$/; function validateBICFI(bic) { if (typeof bic !== "string") return false; return BIC_REGEX.test(bic.trim().toUpperCase()); } console.log(validateBICFI("DEUTDEDBFRA")); // true — 11-char with branch console.log(validateBICFI("NTRSUS33XXX")); // true — 11-char with branch XXX console.log(validateBICFI("CHASUS33")); // true — 8-char, no branch console.log(validateBICFI("BAD")); // false — too short
/** * validateIBAN(iban) * ISO 13616 algorithm: * 1. Remove spaces, uppercase. * 2. Move first 4 characters to the end. * 3. Replace each letter with its numeric equivalent: A=10, B=11, …, Z=35. * 4. Compute the numeric string mod 97. * 5. Valid IBAN → remainder === 1. * * Country-specific length rules are not enforced here; add a lookup table * if strict per-country length validation is required. */ function validateIBAN(iban) { if (typeof iban !== "string") return false; // Step 1: Normalise — remove spaces, uppercase const normalized = iban.replace(/\s+/g, "").toUpperCase(); // Basic structural check: 2 alpha country + 2 digit check + up to 30 alphanum if (!/^[A-Z]{2}[0-9]{2}[A-Z0-9]{1,30}$/.test(normalized)) return false; // Step 2: Rearrange — move first 4 chars to end const rearranged = normalized.slice(4) + normalized.slice(0, 4); // Step 3: Convert letters to digits (A=10 … Z=35) const numeric = rearranged.replace(/[A-Z]/g, ch => ch.charCodeAt(0) - 55); // Step 4 & 5: Compute mod 97 using chunk arithmetic (BigInt avoids precision loss) let remainder = BigInt(numeric) % 97n; return remainder === 1n; } console.log(validateIBAN("GB82 WEST 1234 5698 7654 32")); // true — canonical IBAN test vector console.log(validateIBAN("DE89370400440532013000")); // true — Deutsche Bank DE console.log(validateIBAN("DE89370400440532013001")); // false — bad check digit console.log(validateIBAN("NOTANIBAN")); // false — fails structural check
/** * validateLEI(lei) * ISO 17442 Legal Entity Identifier — 20 characters: * Chars 1–18: alphanumeric entity identifier (issued by an LOU) * Chars 19–20: 2-digit check digits, computed via ISO 7064 MOD 97-10 * (same algorithm as IBAN mod-97). * * Algorithm: * 1. Convert letters to digits: A=10, B=11, …, Z=35 (same mapping as IBAN). * 2. Compute the resulting numeric string mod 97. * 3. Valid LEI → remainder === 1. */ function validateLEI(lei) { if (typeof lei !== "string") return false; // Normalise and structural check: exactly 20 uppercase alphanumeric chars const normalized = lei.trim().toUpperCase(); if (!/^[A-Z0-9]{18}[0-9]{2}$/.test(normalized)) return false; // Convert letters to digits (A=10 … Z=35), digits stay as-is const numeric = normalized.replace(/[A-Z]/g, ch => ch.charCodeAt(0) - 55); // MOD 97-10 check: remainder must equal 1 let remainder = BigInt(numeric) % 97n; return remainder === 1n; } console.log(validateLEI("549300TRUWO2CD2G5692")); // true — valid LEI test vector console.log(validateLEI("5493008IOANM4MK63B46")); // true — Northern Trust LEI console.log(validateLEI("549300TRUWO2CD2G5691")); // false — bad check digit console.log(validateLEI("TOOSHORT")); // false — not 20 chars /** * validateISO20022Payload(payload) * Convenience wrapper — validates all applicable code-list fields in an OCG * output_payload that carries the ISO 20022 profile. * Returns { valid: bool, errors: string[] }. */ function validateISO20022Payload(payload) { const errors = []; const currency = payload?.instructed_amount?.currency; if (currency && !validateISO4217(currency)) errors.push(`instructed_amount.currency "${currency}" is not a valid ISO 4217 code`); for (const role of ["debtor", "creditor"]) { const party = payload?.[role]; if (party?.country && !validateISO3166Alpha2(party.country)) errors.push(`${role}.country "${party.country}" is not a valid ISO 3166-1 alpha-2 code`); if (party?.lei && !validateLEI(party.lei)) errors.push(`${role}.lei "${party.lei}" fails ISO 17442 MOD 97-10 check`); } for (const role of ["debtor_agent", "creditor_agent"]) { const agent = payload?.[role]; if (agent?.bicfi && !validateBICFI(agent.bicfi)) errors.push(`${role}.bicfi "${agent.bicfi}" fails ISO 9362 BIC validation`); } for (const role of ["debtor_account", "creditor_account"]) { const account = payload?.[role]; if (account?.iban && !validateIBAN(account.iban)) errors.push(`${role}.iban "${account.iban}" fails ISO 13616 mod-97 check`); } return { valid: errors.length === 0, errors }; }
The ISO 20022 pacs.008 message (FIToFICustomerCreditTransfer) is the primary inter-bank credit transfer message used in SWIFT CBPR+ and TARGET2/T2. The OCG ISO 20022 profile is designed so that its payload fields align directly with the pacs.008 CdtTrfTxInf (Credit Transfer Transaction Information) block, enabling downstream tooling to map OCG artifacts to pacs.008 elements without ambiguity.
This is alignment for interoperability: OCG does not generate or transmit live pacs.008 messages. The crosswalk is a read direction only: given a completed OCG artifact, a downstream system can derive the pacs.008 field values. The reverse (parsing a live pacs.008 XML/MX message into an OCG artifact) is an application-layer concern.
| OCG payload field | pacs.008 element path | Notes |
|---|---|---|
| instructed_amount.{amount, currency} | CdtTrfTxInf/IntrBkSttlmAmt[@Ccy] | Amount value + Ccy attribute. pacs.008 uses InterbankSettlementAmount; InstructedAmount is an optional additional element. |
| debtor.{party_name, lei, country} | CdtTrfTxInf/Dbtr/Nm, /Id/OrgId/LEI, /PstlAdr/Ctry | PartyIdentification element. LEI maps to OrganisationIdentification/LEI sub-element. |
| creditor.{party_name, lei, country} | CdtTrfTxInf/Cdtr/Nm, /Id/OrgId/LEI, /PstlAdr/Ctry | Same structure as Dbtr. CountryCode (ISO 3166-1 alpha-2) in PostalAddress/Country. |
| debtor_agent.bicfi | CdtTrfTxInf/DbtrAgt/FinInstnId/BICFI | ISO 9362 BIC. Required in CBPR+ for all SWIFT messages. |
| creditor_agent.bicfi | CdtTrfTxInf/CdtrAgt/FinInstnId/BICFI | ISO 9362 BIC. Required in CBPR+. |
| debtor_account.iban | CdtTrfTxInf/DbtrAcct/Id/IBAN | ISO 13616. Required in SEPA and CBPR+ where applicable. |
| creditor_account.iban | CdtTrfTxInf/CdtrAcct/Id/IBAN | ISO 13616. Required in SEPA and CBPR+ where applicable. |
| settlement_date | CdtTrfTxInf/IntrBkSttlmDt | ISO 8601 date (YYYY-MM-DD). pacs.008 uses ISODate type. |
| remittance_information | CdtTrfTxInf/RmtInf/Ustrd or /Strd | Unstructured (Ustrd) or structured (Strd). OCG stores as a string; structured parsing is application-layer. |
The AINumbers suite already includes RCA-03 (verify_address_migration_batch), which validates ISO 20022 pacs.008 PostalAddress24 structured addresses for the SWIFT CBPR+ November 2026 structured-address mandate. That mandate requires replacing free-form address lines with structured PostalAddress24 fields (street name, building number, town name, country sub-division, post code, country). The OCG ISO 20022 profile's country field (ISO 3166-1 alpha-2) aligns directly with the PostalAddress24 Ctry element validated by RCA-03.
OCG artifacts with the ISO 20022 profile are not ISO 20022 messages and cannot be submitted directly to SWIFT or any ISO 20022-compliant financial infrastructure. They are provenance artifacts that carry ISO 20022-aligned field names to enable interoperability tooling. Generating and transmitting live pacs.008 MX messages requires a SWIFT-connected application and appropriate connectivity agreements; this is outside the scope of OpenChainGraph.
The chaingraph.json graph-index file lists all OCG-compatible tools and their nodes. In v0.3, a node may carry an ocg:semantic_profile field that declares which semantic overlay it uses. Crawlers, agents, and integration tooling can filter the index to discover ISO 20022-aligned tools without inspecting each artifact individually.
{
"nodes": [
{
"tool_id": "T290",
"name": "Settlement Mandate Validator",
"mandate_type": "settlement_mandate",
"tool_version": "1.0.0",
"ap2_version": "v0.3",
"ocg:semantic_profile": "iso20022:pacs.008-subset", /* ISO 20022 discovery marker */
"href": "tools/T290-settlement-mandate-validator.html",
"compliance_frameworks": ["CBPR+", "LEI_VALID"]
},
{
"tool_id": "T291",
"name": "CBPR+ Address Validator",
"mandate_type": "compliance_control",
"tool_version": "1.0.0",
"ap2_version": "v0.3",
"ocg:semantic_profile": "iso20022:pacs.008-subset", /* same marker */
"href": "tools/T291-cbpr-address-validator.html",
"compliance_frameworks": ["CBPR+"]
}
]
}
/** * findISO20022Tools(chaingraphJson) * Given the parsed chaingraph.json object, returns all nodes that declare * an ISO 20022 semantic profile. Filters on the ocg:semantic_profile field. */ function findISO20022Tools(chaingraphJson) { const nodes = chaingraphJson?.nodes ?? []; return nodes.filter(node => typeof node["ocg:semantic_profile"] === "string" && node["ocg:semantic_profile"].startsWith("iso20022:") ); } // Usage — fetch the live graph index and find ISO 20022-aligned tools: const resp = await fetch("/chaingraph/chaingraph.json"); const index = await resp.json(); const iso20022Tools = findISO20022Tools(index); console.log(iso20022Tools.map(t => `${t.tool_id}: ${t.name}`)); // ["T290: Settlement Mandate Validator", "T291: CBPR+ Address Validator"] // Narrower filter — only pacs.008-subset profile: const pacs008Tools = iso20022Tools.filter( t => t["ocg:semantic_profile"] === "iso20022:pacs.008-subset" );
The v0.3 ISO 20022 overlay is designed to be fully backwards-compatible with all prior OCG versions and to be diligence-safe in a regulated financial context. The following guarantees and posture notes apply.
All v0.1 and v0.2 artifacts remain valid under v0.3. The overlay is strictly additive: it introduces no required fields and removes no existing fields. A v0.1 artifact without any @context array extension is still a valid OCG artifact. A v0.3 artifact without the ISO 20022 overlay is also valid. The version number in ap2_version signals which overlay set the tool supports, not a breaking change to the core schema.
Every field in the ISO 20022 profile is optional. A tool may carry instructed_amount without debtor, or bicfi without iban. The profile is a menu of available alignment fields, not a mandatory schema. Validators should not fail an artifact for missing ISO 20022 fields unless the tool's own specification declares them required.
The execution_hash preimage is unchanged. It remains the sorted-key SHA-256 over {"policy_parameters": …, "output_payload": …} only, identical to v0.1 and v0.2. The @context array, ocg:semantic_profile, and all JSON-LD framing fields are outside the preimage. A verifier that was correct for v0.1 artifacts will compute the same hash for a v0.3 artifact with no changes to its verification code.
ISO 20022 is a registered international standard. Message type definitions are published by the ISO Registration Authority (ISO/TC68/SC9) and administered operationally by SWIFT, which maintains the ISO 20022 Message Definition Repository. OpenChainGraph is not registered with the ISO RA. Using ISO 20022-aligned terminology in OCG artifacts does not imply conformance to, or registration under, the ISO 20022 normative specification. Compliance officers and auditors should treat OCG's ISO 20022 alignment as a semantic interoperability layer, not a claim of ISO 20022 certification.
LEI is optional and, when present, may be bound to the Ed25519 signing-key identity. The debtor.lei or creditor.lei field in the output payload identifies the party being evaluated. Separately, the audit_signature.signatures[0].keyid field identifies the Ed25519 key that signed the artifact. These two identity anchors can be linked (for example, the publisher's own LEI bound to the signing key) to provide a verifiable chain from the cryptographic signature to the registered legal entity. See the Ed25519 integration guide for key-management and signing-key attestation details.
Six steps to verify that an OCG tool correctly implements the v0.3 ISO 20022 profile. Each step is independently testable.
| Step | Action | Verified by |
|---|---|---|
| 1 | Confirm the tool emits a v0.3 OCG artifact whose @context is an array containing both the base context and the ISO 20022 overlay URL. |
Array.isArray(artifact["@context"]) and artifact["@context"].includes("https://ainumbers.co/chaingraph/context/v0.3/iso20022-context.jsonld") |
| 2 | Map the tool's output payload fields to the ISO 20022 profile field names: instructed_amount, debtor/creditor, debtor_agent/creditor_agent, settlement_date, remittance_information. |
Payload field names match the §2 mapping table. No ad-hoc naming (e.g., amount_eur instead of instructed_amount.amount). |
| 3 | Run validateISO20022Payload(artifact.output_payload) from §4. All five code lists (ISO 4217 currency, ISO 3166-1 alpha-2 country, ISO 9362 BICFI, ISO 13616 IBAN, ISO 17442 LEI) must pass for any field that is present. |
result.valid === true and result.errors.length === 0 |
| 4 | Add "ocg:semantic_profile": "iso20022:pacs.008-subset" to the tool's chaingraph.json graph-index node so that the discovery filter in §6 returns it. |
findISO20022Tools(index).some(n => n.tool_id === YOUR_TOOL_ID) |
| 5 | (Optional) Attach a LEI to the party or publisher identity field and, if applicable, bind it to the Ed25519 signing key as described in the Ed25519 guide. | validateLEI(artifact.output_payload.debtor.lei) === true and the signing-key attestation references the same LEI. |
| 6 | Confirm the execution_hash still verifies unchanged. Recompute SHA-256 over the sorted-key JSON of {policy_parameters, output_payload} and assert it matches artifact.execution_hash. |
Recomputed hash === artifact.execution_hash. The overlay's @context and ocg:semantic_profile fields must not appear in the preimage. |
If your integration involves CBPR+ structured-address compliance, RCA-03 (verify_address_migration_batch) in the AINumbers suite validates pacs.008 PostalAddress24 fields for the SWIFT CBPR+ November 2026 mandate. Running RCA-03 as part of your OCG chain satisfies the structured-address validation requirement independently of the ISO 20022 profile overlay. The two are complementary: the overlay provides semantic alignment; RCA-03 provides regulatory compliance validation.
Seven dedicated OCG nodes cover the full CBPR+ November 2026 structured-address migration and cross-border payment validation pipeline. All seven are gpu: false with proofs deferred (Opus session fills them); all operate on structural or synthetic message fields and never on real party PII.
| Node | MCP tool | Coverage |
|---|---|---|
| ART-241 | lint_cbpr_structured_address |
PostalAddress24 structure type (FULLY_STRUCTURED / HYBRID / UNSTRUCTURED), silent-fail AdrLine duplication detection, CBPR+ Nov 2026 ban check |
| ART-242 | validate_pacs008_party_completeness |
BIS CPMI d218 field completeness: UETR (UUIDv4), debtor/creditor names, BIC (ISO 9362), LEI format (ISO 17442), purpose code format |
| ART-243 | check_purpose_code_requirement |
Jurisdiction-level purpose code mandate check: UAE/India/Bahrain/Jordan/China/Malaysia per BIS CPMI d218; SwiftGo eligibility (amount at most $12,500 + accepted category purpose codes) |
| ART-244 | simulate_gpi_tracker_lifecycle |
SWIFT GPI state machine (PDNG/ACSP/ACWC/ACCC/RJCT), valid transition check, Universal Confirmation 24h SLA breach detection |
| ART-245 | score_mt_mx_translation_fidelity |
MT103 to pacs.008 field mapping fidelity: 7-field coverage (50K/52A/57A/59/70/71A/UETR), charge bearer mapping (OUR/SHA/BEN to DEBT/SHAR/CRED), HIGH/MEDIUM/LOW tier |
| ART-246 | lint_lei_payment_binding |
Wolfsberg Payment Transparency Standards (6 fields, 110-pt scale: HIGH 80+/MEDIUM 50+/LOW), ISO 17442 LEI mod-97 check-digit validation for originator and beneficiary |
| ART-247 | prevalidation_readiness_scorer |
Full prevalidation bundle: IBAN mod-97 (78 countries), BIC format, UETR UUIDv4, LEI format presence, PostalAddress24 silent-fail duplication. Emits ready boolean gate signal. |
cbpr-address-lint-chain (ART-241 → ART-242 → ART-246): address structure lint, party completeness validation, Wolfsberg transparency scoring in sequence.
gpi-mt-to-mx-translation (ART-244 → ART-245): GPI lifecycle state check followed by MT103 to MX translation fidelity scoring.
cross-border-payment-prevalidation (ART-243 → ART-247, gated): purpose code requirement check feeds into full prevalidation scorer; the /ready gate on ART-247 output controls chain continuation per OCG §21.4.
RCA-03 (verify_address_migration_batch) validates batches of migrated pacs.008 address archives. ART-241 (lint_cbpr_structured_address) lints a single PostalAddress24 block per call and specifically detects the silent-fail duplication pattern (structured field values echoed into AdrLine entries) that causes STP rejection without a visible error code. Use ART-241 for per-message pre-submission lint and RCA-03 for bulk migration readiness assessment.