OpenChainGraph v0.3 · Integration How-To

Using OpenChainGraph with ISO 20022

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.

§1

An optional semantic overlay, not a payload rewrite

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.

json OCG v0.3 artifact with ISO 20022-aligned output_payload
{
  "@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"
    }]
  }
}
Hash preimage is unchanged

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.

§2

Field mapping: OCG payload → ISO 20022 business elements

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.
§3

The iso20022-context.jsonld overlay

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).

json-ld https://ainumbers.co/chaingraph/context/v0.3/iso20022-context.jsonld · canonical published file
{
  "@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" }
  }
}
Crosswalk, not registration

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.

§4

Validating the external code lists

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.

javascript (a) ISO 4217 currency: 3-letter uppercase membership check
/**
 * 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
javascript (b) ISO 3166-1 alpha-2 country code: format check
/**
 * 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
javascript (c) ISO 9362 BIC / BICFI: regex validation
/**
 * 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
javascript (d) ISO 13616 IBAN: mod-97 check-digit verification
/**
 * 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
javascript (e) ISO 17442 LEI: ISO 7064 MOD 97-10 check-digit verification
/**
 * 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 };
}
§5

Crosswalk to pacs.008

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.
RCA-03: pacs.008 PostalAddress24 validation (CBPR+ Nov 2026)

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.

Aligned, not registered

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.

§6

Discovery: the semantic_profile marker

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.

json chaingraph.json graph-index node fragment · ISO 20022 profile marker
{
  "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+"]
    }
  ]
}
javascript Filter graph-index nodes by semantic_profile: find ISO 20022-aligned tools
/**
 * 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"
);
§7

Backwards compatibility & diligence posture

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.

Version compatibility

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.

All v0.3 ISO 20022 fields are optional

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.

Hash preimage untouched

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-aligned, not registered: governance note

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 and Ed25519 identity binding

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.

§8

Integration checklist

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.
RCA-03 already covers pacs.008 address validation

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.

§9

CBPR+ Nov 2026 toolchain (ART-241..247)

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.

NodeMCP toolCoverage
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.
Three OCG chains covering end-to-end CBPR+ validation

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.

Silent-fail disambiguation (RCA-03 vs ART-241)

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.