GENIUS Act Stablecoin Compliance Accelerator: Solution Documentation

Transaction adjudication and obligation reasoning for banks, payment intermediaries, issuers and custodians — a Rainbird accelerator

Released as an open Accelerator under the MIT licence for demonstration and evaluation. The pack contains the knowledge graph (graph.xml: 427 rules, 191 relationships, 38 concepts, 256 instances), the Studio test suite (68 tests generated from live runs), this document, the regulatory cross-reference (Regulatory Cross Reference Documentation.md) and the MIT licence. Every institution, coin, wallet, mixer, person and foreign jurisdiction in the graph is fictional and every house threshold is illustrative: calibrate the risk appetite to your own policy and validate the model against your own cases before any production use. The US legal framework is real. Status of the law encoded (as of 14 September 2026): the GENIUS Act (Pub. L. 119-27) is FINAL LAW; the April 2026 joint FinCEN/OFAC PPSI programme NPRM (91 FR 18582) and the June 2026 joint PPSI CIP NPRM (91 FR 37234) are PROPOSED; no final implementing regulations exist, so the statutory effective date of 18 January 2027 governs.

---

1. What this accelerator decides

Layer 1 — transaction-level evaluation. For each stablecoin transaction the graph derives: whether the coin is issued by a permitted payment stablecoin issuer (PPSI) or qualifies under the section 18 foreign-regime exception; the counterparty wallet's sanctions exposure (direct, through hops, through mixers, and through named transfer parties); whether the required Travel Rule information is present and consistent; whether amount/velocity/jurisdiction patterns meet suspicious-activity typologies; and exactly one disposition — Process, Reject, Block, Freeze Pending Lawful Order, File Suspicious Activity Report, Hold Escalate To Sanctions Officer, or Escalate Incomplete Record — each with a certainty, a regulator-ready rationale, the accrued reporting obligations with composed deadlines, recommended next steps, and a one-query case file.

Layer 2 — obligation-level reasoning. For each institution the graph derives which GENIUS Act duties attach to its roles (issuer / custodian / payment intermediary / bank / MSB), whether its AML/CFT and sanctions programmes satisfy the statutory elements, the proposed 2026 programme elements, and the OFAC framework pillars, a three-valued programme assessment (Adequate / Deficient / Not Fully Evidenced — an unevidenced element never counts as satisfied), composed remediation items, and what the non-compliant-foreign-stablecoin prohibition timeline means for its acceptance policy.

Authority-status discipline. Every evidence and rationale string carries one of four labels — FINAL LAW / PROPOSED / GUIDANCE / HOUSE POLICY — so a regulator reading a case file can always tell a statutory duty from a board-approved risk-appetite choice. House numerics cite the institution's Risk Appetite Statement, never a regulation.

Era model. The injected evaluation date drives three regimes: Era 1 pre-effective (before 18 Jan 2027, or earlier if final regulations issue — the graph computes the section 20 earlier-of formula from an injectable finals-issuance date), Era 2 effective, Era 3 DASP prohibition (from 18 Jul 2028, three years after enactment, no extension authority — only the narrow 5902(c) Treasury safe harbor, which is modelled).

2. Provenance

The graph is grounded in sixteen public sources: the GENIUS Act and its codification, the 2026 joint FinCEN and OFAC rulemakings, the BSA travel rule and SAR rules, the OFAC reporting regime, guidance and enforcement, and FinCEN's advisories, all listed with their URLs in the pack's web sources. Regulatory Cross Reference Documentation.md carries the requirements register every rule name traces to, the provenance in both directions (source to rules, and rules to source with the authority label of each family), and the source verification notes as of 14 September 2026. Where the law prescribes no figure, the value is house policy on the Risk Appetite instance and is labelled as such in every evidence line.

3. Architecture

Layered pipeline, exactly-one outcomes by count-guarded precedence ladders:

injected feeds (payments, screening, blockchain analytics, registry, orders, policy)
  → era derivation (sec. 20 earlier-of formula)
  → coin permission status (candidates → most-restrictive-wins ladder)
  → section 8 noncompliance state machine (notice → cure → FR publication → ban → waiver/lift)
  → acceptance determination (statutory bars → house policy → safe harbor → wind-down → accept;
     fail-safe default deny)
  → wallet exposure tier (regulatory floor → severe → elevated → watch → clean-on-complete-record)
  → travel rule status (field findings → chain-role-aware status ladder)
  → suspicion signals (graded cf 85/70/60) → role-aware SAR threshold → SAR obligation
  → property-interest fork → issuer-anchored lawful-order gate
  → disposition candidates → ladder: Freeze > Block > Reject > Escalate > Hold > File > Process
  → reporting obligations (accrue independently of the ladder) → controlling rationale (exactly one)
  → next steps → case-file composite (one plural query returns the whole case, PREFIX :: lines)
  + obligation layer: role duties (era-gated) → required elements → three-valued element status
    → programme assessment ladder → remediation items

Design principles carried throughout: unknown never approves (Clean/Process/Adequate require complete explicit records; missing records escalate); two-sided determinations (explicit false ≠ absent); mark-based statutory overrides (safe harbor and reciprocal-reserve marks derive only from explicit-true facts, so absent and false both preserve the default prohibition); weight-1 gates (outcome certainty tracks the decisive carrier fact, so a 90-confidence analytics feed yields a 90-confidence tier); mirror-gated evidence (every narrative line copies the guards of the outcome it narrates); reporting decoupled from disposition (a Freeze that outranks a Block still accrues the OFAC blocking report).

Askability posture. Every systems-of-record input is askable="none" and injected (payments feed, analytics feed, registry, policy). Exactly five facts are askable questions, because only a human can answer them: the transaction's stated business purpose, analyst confirmation of a property interest, whether the counterparty VASP answered the RFI, whether wallet ownership was verified with the customer, and whether legal authenticated a lawful order. All carry allowUnknown.

4. Query surface

Query (subject → relationship)	Returns
<txn> → has disposition	exactly one of the seven dispositions, with certainty
<txn> → has disposition rationale	the single controlling, regulator-ready rationale
<txn> → has reporting obligation / reporting deadline narrative	accrued OFAC/BSA reports with composed deadlines
<txn> → has recommended next step / has contributing evidence / exhibits suspicion signal	operational layer
<txn> → has case file line	the ENTIRE case file as PREFIX :: value lines (SIGNAL, TRSTATUS, TIER, ACCEPT, ACCEPTLINE, SEC8, ERA, EVID, REPORT, DEADLINE, NEXT, RATIONALE, MARKETING)
<coin> → has permission status / has acceptance determination / acceptance policy line / has sec8 state	coin-level layer
<wallet> → has exposure tier / wallet evidence line	wallet-level layer
<entity> → has genius duty / duty basis line / has programme assessment / has remediation item / element deficient / state pathway line	obligation layer

Datasource pattern: the payments system injects transaction facts; the blockchain-analytics feed injects wallet facts (at its own vendor confidence, e.g. 90); the registry feed injects coin/issuer facts; the sanctions screening feed injects party listing facts; the policy singletons (GENIUS Policy, Risk Appetite) hold thresholds as one-line-editable facts. GENIUS Policy has evaluation date is injected per session and drives the era. <txn> is evaluated by <entity> is the mandatory anchor for every transaction.

5. Verification

The Studio test suite ships 68 tests, every one generated from a live run and shaped Inject, then Query, then Expect Result with no question steps; every expectation is engine-exact and sits on its own step. It covers four grades:

• Transaction scenarios (35): a clean permitted federal coin processed at certainty 97; house-policy and statutory acceptance rejects; an SDN-listed wallet blocked where the property is held and rejected with OFAC reporting where it is not; the travel-rule ladder (an intermediary's missing address under the house reject stance, a missing originator name withheld for correction on the ordering side, and wholly missing records escalated); a KYC mismatch filed above the SAR threshold and processed below it with the voluntary SAR note; a pseudonymous originator; a valid lawful order frozen at the issuer; structuring, velocity, mixer layering, sanctions-evasion timing and pig-butchering signals filed at certainties that track each signal; a prohibited jurisdiction; direct, elevated and watch-tier mixer exposure; state-qualified, foreign-qualifying and reciprocal-arrangement coins; an unknown issuer and a split-domicile refer-out escalated; an SDN-listed transfer party; the Era 3 Treasury safe harbor; a case processed with enhanced due diligence; a dusting receipt with the relaxed reporting timeline; comparability rescission inside and beyond the wind-down window; an unknown mixer listing and an unknown originator party escalated; and an Era 1 pre-effective house reject.
• Obligation personas (6): the issuer, the state-pathway issuer with its ceiling intact, a deficient money services business with its remediation items, the bank and the custodian, each with its role-correct duty set and programme assessment, plus the issuer at an Era 1 evaluation date.
• Adversarial probes (20): anchor-only and sparse payloads that must escalate and never process; an SDN wallet that stays prohibited; a contradictory property record that resolves to Block; a safe harbor that stays inert; a reciprocal arrangement; transition-waiver duties; a seizure order whose freeze keeps its reporting obligations; a party Reject outranking severe exposure; a house decline outranking an escalation with no analytics; exposure exactly at the hold threshold and at the review floor, at hop depth two and three; the dusting boundary; missing travel-rule records; the section 8 ban-pending and ban-active states; and an unknown mixer counterparty.
• Statutory boundary tests (7): the era boundaries on either side of the effective date and of the DASP prohibition date, a finals date pulling the effective date forward, and the section 8 cure window running and lapsed on its boundary day.

Design guarantees the suite pins throughout: unknown never approves, explicit false is not absence, exactly one disposition per transaction, and reporting accrues independently of the disposition ladder.

6. Using and testing the accelerator

RAKE and Studio: import the pack into RAKE to open the graph, tests and documentation as a project (the graph deploys as graph.xml and the MCP connection guide is generated on import), or import the graph XML into Rainbird Studio directly. Then load the Studio test suite (Rainbird Studio Test Suite (Main and Adversarial).json) and run all 68: every test is Inject, Query, Expect Result and should pass with the recorded certainties. If you edit policy facts (thresholds, house stances), re-baseline the affected expectations.

API: start a session on the deployed graph, inject the scenario facts as one array, then query {subject, relationship} for the goals in the query surface above; answer any question the engine raises through the response endpoint; unknown skips need allowUnknown, which all five askables carry. All OFAC, BSA and GENIUS thresholds are injectable policy facts for what-if analysis.

MCP: published to an MCP endpoint, the graph lets any MCP client inject scenario facts and request dispositions programmatically; the connection guide generated on import lists the goals and injectables. Inject facts first, then query. Every session needs GENIUS Policy has evaluation date and each transaction needs is evaluated by; inject the five analyst facts for question-free runs, and use the explain tool on any result's factID for the derivation narrative.

7. Data contract (per session)

• Exactly one evaluating institution per session; <txn> is evaluated by <entity> is mandatory.
• GENIUS Policy has evaluation date injected once per session (drives the era); optional has finals issuance date models the 120-day prong.
• One value per singular relationship per session (contradictory injections are first-write-wins).
• Wallet analytics facts inject at the vendor's confidence (e.g. 90) — outcome certainty tracks it.
• has reciprocal reserve arrangement / covered by treasury safe harbor / has transition waiver: inject true only when the determination actually exists; absence and explicit false are equivalent (the prohibition/duty stands).
• Plural askables do not exist on this surface; the five singular askables are question-suppressed by injecting them (cf 100) — the shipped tests do exactly that.
• Studio-suite note: expected certainties are engine-exact from live runs; if you edit policy facts (thresholds, house stances), re-baseline the affected expectations.
• The acceptance layer binds through <entity> is evaluating acceptance of <coin>: inject it for the evaluating institution and the transaction's coin, as every shipped transaction test does.
• When padding the analyst facts for question-free runs, property interest confirmed must match the polarity of institution holds transaction asset, as the shipped tests do.