Rule-pack pinning is iso-compliant's mechanism for protecting customers from upstream bank-rule changes. Every tenant pins a specific rule-pack version per bank — say ubs-ch@2026.06 — and emits pain.001 / pain.008 against that pinned version's overlay until the tenant explicitly upgrades.
The rule-pack registry at apps/api/rule-packs/ is content-addressed: each pack ships as a directory with a manifest (pack.json), the schema-overlay JSON, and a SHA-256 of the directory tree. The version string is a calendar-versioned tuple (YYYY.MM plus an optional patch suffix) so an upgrade is unambiguous and reversible.
When a bank publishes a new rule (a new mandatory field, a tightened validation rule, a deprecated value), iso-compliant ships a new pack version. Tenants on the old version see no change — their pain.001 keeps building against the old overlay until they explicitly bump the pinned version (via the dashboard or the tenant_settings.rule_pack_pins row).
The benefit: a Friday-night bank rule change does not break Monday's payroll. The cost: tenants must occasionally do an upgrade cycle, with a UAT against the new pack before pinning it. iso-compliant's upgrade tooling diffs the old pack vs the new pack and highlights breaking changes per field.
The loader lives at apps/api/src/lib/rule-pack-loader.ts; the registry index at apps/api/rule-packs/manifest.json. The current Tier-1 packs are documented at /banks; the loader falls back to a CBPR+ baseline when no pack is pinned (the safe default for any cross-border flow).