Which CBDC programs does the attestation cover?

The mechanism is built to normalize any declared central bank digital currency program - the implementation names e-CNY, a digital-euro-style rail, a UK-style rail, and Caribbean programs (Sand Dollar, JAM-DEX) as configured examples - across a common wallet-status, restriction, bridge-integrity, and velocity schema.

What triggers an automatic hard block?

A recipient wallet whose status has been set to suspended by its issuing central bank produces an immediate hard block, independent of any other scoring.

How are per-CBDC velocity ceilings enforced?

The engine maintains a rolling 24-hour aggregate of a sender's transaction volume for the specific CBDC type and compares it against an issuer-specific or internally configured daily ceiling, adding a risk contribution when the ceiling is breached.

Unified Cross-CBDC Programmable-Money Compliance Attestation

Executive Summary

Central bank digital currency programs each define their own compliance surface. e-CNY, digital-euro-style proposals, and Caribbean CBDCs such as Sand Dollar and JAM-DEX each impose different wallet-tiering rules, different programmable-money restriction primitives, and different daily velocity ceilings, with no common API across programs.

JIL Sovereign's CBDC attestation signal normalizes these into one compliance output: recipient wallet status (suspended or unregistered), programmable-restriction violations (scored per violation), bridge-protocol integrity (mBridge and Dunbar interoperability checks), and a per-CBDC daily velocity ceiling evaluated against a rolling internal aggregate - all expressed through the same schema regardless of which CBDC program the transaction touches.

Core Innovation: A single compliance-attestation function that ingests four structurally different CBDC-specific inputs - issuer-defined wallet tiering, programmable-restriction rule violations, multi-CBDC bridge-protocol integrity, and per-currency velocity ceilings - and produces one normalized signal usable by a transaction verdict engine regardless of which CBDC program is involved.

Problem Statement

As CBDC pilots and live retail programs multiply across jurisdictions, financial infrastructure providers that need to interoperate with multiple CBDC rails face a fragmentation problem: each central bank publishes its own wallet-tier, transaction-limit, and programmable-money rules, rarely in a common machine-readable schema. A transaction verdict engine that wants to support e-CNY-style, digital-euro-style, and Caribbean CBDC corridors today either hard-codes each program's logic as a bespoke integration, or skips CBDC compliance entirely and treats CBDC transfers as generic fiat movements - missing the program-specific restrictions that make CBDCs distinct from conventional digital money in the first place.

4

compliance pillars normalized: wallet, restriction, bridge, velocity

2

interoperability bridge protocols checked: mBridge, Dunbar

1

common schema across all CBDC programs

Technical Architecture

Four Normalized Compliance Pillars

Pillar	Trigger	Score Contribution
Wallet status	Recipient wallet suspended by issuing central bank	Immediate hard block (100)
Wallet status	Recipient wallet unregistered	+70
Programmable restriction	Each declared restriction violation	+50 per violation (compounding)
Bridge integrity	mBridge protocol integrity check fails	+60
Velocity	Rolling 24h aggregate for the CBDC type exceeds its ceiling	+45

The signal is triggered at a score of 30 or above, and independently hard-blocked at a score of 85 or above, or immediately on wallet suspension.

CBDC Programs and Bridge Protocols Modeled

Category	Identifiers
CBDC types	`eCNY`, `DEUR`, `GBPP`, `SAND_DOLLAR`, `JAM_DEX`
Bridge protocols	`mBridge`, `Dunbar`

Per-CBDC velocity ceilings are issuer-published or internally configured per program - for example, a tier-3 e-CNY wallet's daily ceiling in the configuration used illustratively here is CNY 50,000, while smaller Caribbean-program ceilings are set far lower. These figures are configuration inputs to the engine, refreshed as issuing central banks publish or amend their own limits, not fixed constants asserted by JIL.

Prior Art Differentiation

Approach	Cross-Program Reuse?	Models Programmable Restrictions?	Models Bridge Integrity?
Bespoke single-CBDC pilot integrations	No - one build per program	Program-specific, not portable	Rarely
Conventional fiat/stablecoin compliance engines	N/A - treats CBDC as generic fiat	No	No
JIL Sovereign	Yes - one schema, multiple programs	Yes	Yes - mBridge, Dunbar

Patent Claim

Independent Claim 130: A computer-implemented method for generating a unified compliance attestation across heterogeneous central bank digital currency programs, comprising: receiving a transaction identifying one of a plurality of distinct central bank digital currency types, a recipient wallet status, a set of declared programmable-money restriction violations, and, where applicable, a cross-CBDC bridge protocol integrity indicator; generating a hard-block determination when the recipient wallet status indicates suspension by its issuing central bank; computing an accumulated risk contribution from the count of declared programmable-restriction violations and from any cross-CBDC bridge protocol integrity failure; comparing a rolling aggregate transaction volume for the identified central bank digital currency type against an issuer-specific velocity ceiling; and combining the wallet-status, restriction-violation, bridge-integrity, and velocity determinations into a single compliance signal expressed in a common schema independent of the specific central bank digital currency program involved.