Autonomous Transaction Compliance Engine with Zone-Partitioned Settlement

Executive Summary

ATCE (Automated Trust & Compliance Engine) is a single, pure, deterministic policy evaluator that runs identically on every validator in JIL's consensus layer, gating a transaction on identity assurance level, attestation presence, sanctions status, live risk score, and bilateral jurisdiction membership, in a fixed check order so that the first failing reason is stable across every node re-running the same evaluation. Because the evaluator performs no clock reads, no random-number generation, no floating-point arithmetic, and has no map-iteration-order dependency, every validator that runs the evaluator over the same policy-and-context pair produces byte-identical output - the compliance decision is a deterministic function of consensus-visible inputs, not an off-chain judgment call layered on top of consensus.

The same evaluator, unmodified, is reused as two distinct enforcement points in the system: the per-transfer "Financial DNA" gate for a regulated on-chain currency object, and the arrival-side gate for a cross-cell federation payment - zone-partitioned settlement, where a payment crossing from one jurisdictional zone (cell) to another is evaluated against the same fixed policy logic regardless of which enforcement point invoked it, so a compliance fix applied once is applied everywhere it's enforced.

Every verdict - allow or deny - is committed as a SHA-256 hash over the exact policy, context, and reason that produced it, anchorable to JIL's court-admissible attestation layer, so a denied transaction's specific reason is provably and reproducibly the one recorded, not something asserted after the fact.

Core Innovation: One deterministic, in-consensus policy evaluator - no clocks, no RNG, no floating point - reused unmodified as both the per-transfer currency compliance gate and the federation cross-cell arrival gate, with every verdict committed as a reproducible hash.

Problem Statement

Most on-chain compliance today is enforced off-chain: a centralized issuer maintains a blacklist and updates a smart contract's allow/deny mapping out of band, or a transfer is screened by a service that runs after the fact and can flag but not deterministically block a transaction at the moment of settlement. That leaves two open problems for a regulated on-chain instrument: validators cannot independently verify that a compliance decision was applied correctly, because the decision logic isn't part of what they're reaching consensus on; and the same compliance logic tends to be re-implemented separately for each enforcement surface - a transfer gate here, a bridge gate there - so a fix in one place does not automatically propagate to the other.

Technical Architecture

Fixed Evaluation Order

Order	Check	Reason Code on Failure
1	Profile is well-formed (non-empty, bounded jurisdiction set, valid risk threshold)	ProfileMalformed
2	Required attestation is present, if the profile demands one	MissingRequiredAttestation
3	Identity assurance level meets the profile's required minimum	IdentityBelowRequired
4	No sanctions hit, if the profile denies on sanctions hit	SanctionsHit
5	Live risk score is below the profile's deny threshold	RiskScoreTooHigh
6	Origin jurisdiction is on the profile's allow-list	OriginJurisdictionBlocked
7	Destination jurisdiction is on the profile's allow-list	DestinationJurisdictionBlocked
8	Amount is positive and within the profile's per-transaction ceiling	AmountOverPerTxLimit

Identity Assurance Scale

Identity levels are strictly ordered - None, Basic, KYC, KYB, Institutional - mirroring NIST 800-63 identity-assurance tiers plus an additional KYB tier for institutional counterparties. A context that does not meet a profile's required level is denied regardless of any other factor.

Dual Reuse Across Enforcement Points

The federation module's arrival-gate function and the currency-platform module's per-transfer gate function each call the identical evaluator - the same code path, not a re-implementation - so both the "Financial DNA" gate and the cross-cell border gate inherit every guarantee (determinism, fail-closed defaults, fixed check order) from one shared, independently-testable primitive.

Fail-Closed Defaults

An unconfigured per-transaction ceiling of zero means "no transfer permitted," not "unlimited" - the fail-closed direction is baked into the zero value's own meaning, not left to a caller's discretion. The same discipline applies to the risk-deny threshold and the jurisdiction allow-list: an empty or malformed policy denies everything rather than defaulting open.

Zone-Partitioned Settlement

A "zone" is a jurisdictional cell within JIL's federation topology. A cross-zone transaction is evaluated on departure by the sending zone's policy and, using the identical evaluator, on arrival by the receiving zone's policy - so both sides of a crossing enforce compliance using the same deterministic logic, with identity attestations traveling with the transaction rather than being independently re-derived at each side of the crossing.

Prior Art Differentiation

Model	In-Consensus?	Same Logic Reused Across Enforcement Points?	Deterministic/Reproducible Verdict Hash?
Centralized stablecoin blacklist (typical regulated token)	No - off-chain list updates an on-chain mapping	No - separate logic per surface	No
Post-hoc transaction monitoring (Chainalysis, TRM, Elliptic)	No - screens after broadcast, can alert but not deterministically block at settlement	No - a separate product per surface	No - alerts are not consensus-committed
JIL ATCE	Yes - runs identically on every validator as part of block execution	Yes - identical function serves the currency transfer gate and the federation border gate	Yes - SHA-256 over (profile, context, reason)

Patent Claim

Independent Claim 19: A computer-implemented method for enforcing transaction compliance within a blockchain consensus layer comprising: evaluating, identically on each of a plurality of validators as part of block execution, a deterministic policy function over a transaction context comprising an identity assurance level, an attestation-presence flag, an origin jurisdiction, a destination jurisdiction, a transaction amount, a risk score, and a sanctions-hit flag, against a policy profile specifying a required identity assurance level, an allowed-jurisdiction set, a per-transaction amount ceiling, and a risk-score deny threshold; producing a verdict comprising an allow-or-deny determination and a stable reason code selected according to a fixed evaluation order such that the first-failing check determines the reason across all validators; computing a cryptographic commitment hash over the policy profile, the transaction context, and the reason code; and invoking the same deterministic policy function, without modification, both as a per-transfer gate for a regulated on-chain currency object and as an arrival-side gate for a transaction crossing between two jurisdictional settlement zones, such that a single policy-logic change applies identically to both enforcement points.