aura-labs.ai

AURA Settlement Rail Architecture

Document Purpose: Specification of the interface between AURA’s clearinghouse (market layer) and external settlement providers (payment rail layer). Defines the settlement instruction contract, proof of settlement model, per-rail finality definitions, failure handling, and reconciliation procedures. Owner: Marc Massar, AURA Labs Version: 1.1 Last Updated: April 14, 2026 Protocol: v2.2 Status: Architecture Designed (DEC-045) Authority: DEC-045 (Settlement Rail Architecture), DEC-043 (Clearinghouse Architecture) References: CLEARINGHOUSE.md (Section 3.4 Settlement Orchestrator, Section 3.8 Custody Adapter Layer), PROTOCOL_SPECIFICATION.md v2.2 (Section 10.7, Section 13.6), MARKET_PROFILES.md (Section 3.4 Risk Configuration)

1. Boundary Definition

1.1 What AURA Decides

AURA is the market. It determines:

AURA does NOT move money. It produces a settlement instruction — a signed, structured, idempotent directive that tells a payment rail what to do.

1.2 What the Rail Decides

The settlement rail is the plumbing. It determines:

The rail produces a proof of settlement — a verifiable, non-repudiable confirmation that funds moved as instructed.

1.3 The Interface

┌──────────────────────┐                        ┌──────────────────────┐
│   AURA Clearinghouse │                        │   Settlement Rail    │
│                      │                        │   (RTP, Stripe,      │
│  Risk Engine         │  Settlement            │    Stablecoin, etc.) │
│  Business Rules Gate │  Instruction           │                      │
│  Margin Calculator   │ ─────────────────────> │  Fund Movement       │
│  Clearing Lifecycle  │                        │  Compliance          │
│  Reserve Manager     │  Proof of              │  Finality            │
│  Adjudicator         │  Settlement            │  Reporting           │
│                      │ <───────────────────── │                      │
└──────────────────────┘                        └──────────────────────┘
         │                                                │
         │           Reconciliation Report                │
         │ <───────────────────────────────────────────── │
         │                                                │
         │           Exception Notification               │
         │ <───────────────────────────────────────────── │

This boundary is absolute. AURA never interacts with the rail’s internal mechanics. The rail never evaluates AURA’s risk decisions. Each system trusts the other’s domain authority and verifies through the interface contract.

2. Settlement Instruction

2.1 Structure

A settlement instruction is the atomic unit of communication from AURA to a rail. It is a signed, idempotent directive.

{
  "instruction_id": "stl_01HXYZ...",
  "idempotency_key": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "instruction_type": "collect",
  "clearing_transaction_id": "clr_01HXYZ...",
  "transaction_id": "txn_01HXYZ...",
  
  "amount": {
    "value": "349.99",
    "currency": "USD"
  },
  
  "source": {
    "principal_id": "prn_01HXYZ...",
    "settlement_wallet": "sw_01HXYZ...",
    "rail_account_reference": "acct_buyer_ref_abc123"
  },
  
  "destination": {
    "principal_id": "prn_01HABC...",
    "settlement_wallet": "sw_01HABC...",
    "rail_account_reference": "acct_seller_ref_def456"
  },
  
  "terms": {
    "payment_method": "rtp",
    "timing": "on_commit",
    "dispute_window_days": 30,
    "risk_margin_amount": "8.75",
    "risk_margin_currency": "USD"
  },
  
  "authorization": {
    "clearing_status": "authorized",
    "risk_score": 0.12,
    "business_rules_passed": true,
    "consent_tier": "explicit",
    "authorized_at": "2026-04-13T14:30:00.000Z"
  },
  
  "cryptographic_proof": {
    "instruction_hash": "sha256:a1b2c3d4...",
    "signed_by": "core_ed25519_public_key",
    "signature": "sig_01HXYZ...",
    "chain_reference": "L6_commitment_hash"
  },
  
  "metadata": {
    "created_at": "2026-04-13T14:30:01.000Z",
    "expires_at": "2026-04-13T15:30:01.000Z",
    "aura_version": "2.0.0",
    "profile_id": "prf_retail_consumer_v1"
  }
}

2.2 Instruction Types

Type Direction When Description
collect Buyer → Escrow At commitment (or at fulfillment for physical goods) Collect funds from buyer into clearing escrow
authorize Buyer → Hold At commitment Place a hold on buyer’s funds (card auth, wallet lock) without moving money
capture Hold → Escrow At fulfillment Convert a hold into a settlement (two-phase)
disburse Escrow → Seller At clearing (after dispute window) Release net proceeds to seller
margin_hold Settlement → Reserve At clearing Segregate risk margin from settlement amount into reserve account
margin_release Reserve → Seller At clearing completion Release margin to seller (minus fees) after dispute window
refund Escrow → Buyer On dispute upheld Return funds to buyer from escrow or reserve
fee Settlement → Operator At clearing Deduct clearing fee
void Cancel Hold On cancellation before capture Release authorization hold without settlement

2.3 Instruction Guarantees

Idempotency. Every instruction carries a unique idempotency_key. A rail that receives the same key twice MUST return the result of the first execution, not execute again. This is the primary mechanism for safe retry.

Immutability. Once created, a settlement instruction is never modified. If terms change (e.g., partial refund), a new instruction is created referencing the original.

Cryptographic binding. The instruction_hash is a SHA-256 of the canonical JSON (sorted keys, no whitespace) of the instruction body excluding the cryptographic_proof field. The hash is signed by Core’s Ed25519 key. The chain_reference links to the L6 commitment hash from the intent chain (Protocol Specification Section 11.10), creating a cryptographic chain from human intent through to settlement instruction.

Expiry. Every instruction has an expires_at timestamp. A rail MUST reject instructions received after expiry. AURA creates a new instruction (with new idempotency key) if retry is needed after expiry.

2.4 Canonical Signing Format

The settlement instruction signature uses the same newline-delimited canonical format as offer signatures (Protocol Specification Section 8.2):

AURA-SETTLEMENT-INSTRUCTION-v1
stl_01HXYZ...
collect
349.99
USD
prn_01HXYZ...
prn_01HABC...
rtp
2026-04-13T14:30:01.000Z
L6_commitment_hash

Core signs with its Ed25519 private key. Rails verify with Core’s published public key.

3. Proof of Settlement

3.1 What Constitutes Proof

A proof of settlement is the rail’s attestation that funds moved as instructed. It must be:

  1. Verifiable — AURA can independently confirm the proof is authentic (cryptographic signature, reference to external system of record, or both)
  2. Non-repudiable — The rail cannot later deny the settlement occurred
  3. Final — The proof represents an irrevocable transfer per the rail’s finality definition
  4. Referenceable — Contains an external reference that can be independently queried

3.2 Proof Structure

{
  "proof_id": "prf_stl_01HXYZ...",
  "instruction_id": "stl_01HXYZ...",
  "idempotency_key": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  
  "status": "confirmed",
  "rail": "rtp",
  
  "settlement_details": {
    "amount_settled": "349.99",
    "currency": "USD",
    "settled_at": "2026-04-13T14:30:05.000Z",
    "finality_type": "irrevocable",
    "finality_achieved_at": "2026-04-13T14:30:05.000Z"
  },
  
  "external_references": {
    "rail_transaction_id": "RTP20260413143005ABC",
    "rail_confirmation_code": "CONF-789012",
    "network_message_id": "MSG-2026041314300500001"
  },
  
  "verification": {
    "method": "rail_signature",
    "signature": "rail_sig_01HXYZ...",
    "public_key_reference": "https://rail.example.com/.well-known/settlement-keys",
    "certificate_chain": ["rail_cert_01...", "root_ca_cert_01..."]
  },
  
  "metadata": {
    "rail_version": "1.0",
    "region": "us-east",
    "received_at": "2026-04-13T14:30:06.000Z"
  }
}

3.3 Proof Verification

AURA verifies every proof of settlement before advancing the clearing lifecycle from settling → settled:

  1. Signature verification. If the rail provides a cryptographic signature, AURA verifies it against the rail’s published public key. Key rotation is handled via the public_key_reference URL.
  2. Amount confirmation. The amount_settled must match the instruction’s amount.value exactly. Partial settlements are rejected unless the instruction type explicitly permits them (e.g., partial_capture).
  3. Reference correlation. The instruction_id and idempotency_key in the proof must match the original instruction.
  4. Finality check. The finality_type must be irrevocable for the clearing lifecycle to advance. Rails that provide provisional finality (e.g., ACH before the return window closes) hold the clearing state at settling until finality is achieved.
  5. Timeliness. The proof must arrive within the clearing window. If the window expires without proof, the instruction enters exception handling (Section 6).

3.4 Proof Storage

Every proof is stored in the settlement_instructions table:

The proof becomes part of the forensic record (CLEARINGHOUSE.md Section 8). An auditor can trace from human intent (L1) through commitment (L6) through settlement instruction through proof of settlement — a complete, cryptographically linked chain from desire to fund movement.

4. Rail Adapter Interface

4.1 Adapter Contract

Every rail adapter implements a common interface. The clearinghouse interacts with all rails through this contract — it never touches rail-specific mechanics directly.

interface SettlementRailAdapter {
  // Submit a settlement instruction to the rail
  submit(instruction: SettlementInstruction): SubmitResult
  
  // Query the status of a previously submitted instruction
  status(instruction_id: string, idempotency_key: string): StatusResult
  
  // Cancel a pending instruction (if the rail supports cancellation)
  cancel(instruction_id: string): CancelResult
  
  // Verify a proof of settlement returned by the rail
  verify(proof: SettlementProof): VerificationResult
  
  // Get the rail's capabilities and constraints
  capabilities(): RailCapabilities
}

4.2 Rail Capabilities Declaration

Each adapter declares its capabilities so the clearinghouse can route instructions appropriately:

{
  "rail_id": "rtp_us",
  "display_name": "Real-Time Payments (RTP)",
  "provider": "RTP Network Operator",
  
  "capabilities": {
    "instruction_types": ["collect", "disburse", "refund"],
    "currencies": ["USD"],
    "settlement_speed": "real_time",
    "finality_type": "irrevocable",
    "finality_latency_ms": 5000,
    "max_amount": 1000000.00,
    "min_amount": 0.01,
    "supports_authorization_hold": false,
    "supports_partial_settlement": false,
    "supports_cancellation": false,
    "supports_batch": false,
    "operating_hours": "24x7x365",
    "proof_method": "rail_signature",
    "idempotency_guaranteed": true
  },
  
  "constraints": {
    "requires_account_verification": true,
    "requires_kyc_level": "entity_verified",
    "jurisdictions": ["US"],
    "excluded_categories": [],
    "regulatory_framework": "Federal Reserve Regulation J, UCC Article 4A"
  },
  
  "integration": {
    "api_version": "1.0",
    "authentication": "mutual_tls",
    "webhook_supported": true,
    "polling_supported": true,
    "sandbox_available": true
  }
}

4.3 Adapter Implementations (Initial Set)

4.3.1 Real-Time Payments (RTP)

Attribute Value
Settlement speed Real-time (seconds)
Finality Irrevocable on confirmation. Credit transfer is final per Federal Reserve Regulation J.
Max amount $1,000,000 per transaction (RTP network limit)
Operating hours 24×7×365
Currency USD only
Authorization holds Not supported. RTP is credit-push only — funds move immediately.
Batch netting Not supported natively. AURA can batch at the instruction level before submission.
Account requirements Both parties need accounts at RTP participant banks. Settlement wallets map to bank account references.
Proof method Rail-signed confirmation message with network message ID
AURA clearing integration Ideal for on_commit timing (immediate collection). For on_fulfillment, AURA holds authorization at the market layer until fulfillment triggers the RTP instruction.

Instruction mapping:

Finality definition: An RTP payment is final when the receiving participant bank sends the confirmation message. This typically occurs within seconds. AURA treats the confirmation as irrevocable — no return codes, no chargebacks, no reversal window. Disputes are handled at the AURA market layer (reserve-funded), not at the rail layer.

Key advantage for AURA: RTP’s irrevocable finality eliminates the settlement risk that exists with ACH (return window) and cards (chargeback window). When AURA’s clearinghouse authorizes a settlement via RTP, the settling → settled transition is seconds, not days. The risk reserve still holds for the negotiated dispute window, but the underlying funds are confirmed.

4.3.2 FedNow

Attribute Value
Settlement speed Real-time (seconds)
Finality Irrevocable on acknowledgment. Federal Reserve settles in central bank money.
Max amount $500,000 per transaction (default limit, adjustable per participant)
Operating hours 24×7×365
Currency USD only
Proof method Federal Reserve acknowledgment message
AURA clearing integration Same as RTP. Preference between RTP and FedNow based on participant bank availability and amount limits.

Instruction mapping: Identical to RTP. Both are credit-push, real-time, irrevocable.

Key difference from RTP: FedNow settles in central bank money (Federal Reserve balances). RTP settles in commercial bank money with prefunded positions at the Federal Reserve. For AURA’s purposes, the finality guarantee is equivalent. Routing between RTP and FedNow is a deployment decision based on participant bank connectivity.

4.3.3 Stablecoin (USDC on Ethereum / L2)

Attribute Value
Settlement speed Near-real-time (block confirmation dependent)
Finality Probabilistic → practical (12 confirmations on Ethereum mainnet; 1 confirmation on L2)
Max amount No protocol limit (gas cost scales, not amount)
Operating hours 24×7×365 (blockchain native)
Currency USDC (USD-pegged)
Authorization holds Supported via smart contract escrow (allowance + escrow contract)
Batch netting Supported (batch contract execution)
Account requirements Ethereum address. Settlement wallet maps to wallet address.
Proof method On-chain transaction hash + block confirmation count. Independently verifiable by anyone.
AURA clearing integration Primary rail for agent-to-agent settlement. Smart contract holds escrow for dispute term.

Instruction mapping:

Finality definition: AURA treats a transaction as final after:

The clearing lifecycle transitions settling → settled after the confirmation threshold is met. The finality_achieved_at timestamp reflects the block timestamp of the confirming block.

Smart contract escrow: The escrow contract is the on-chain implementation of AURA’s reserve manager for stablecoin transactions. It holds funds, enforces time-locked releases (dispute window), and executes payouts on adjudication decisions. The contract’s logic mirrors the clearinghouse’s reserve operations (hold, release, draw, fee) but executes them on-chain with cryptographic enforcement rather than database-level controls.

4.3.4 Card (Stripe Adapter — Transitional)

Attribute Value
Settlement speed T+1 to T+2 (batch settlement from Stripe to AURA’s bank account)
Finality Provisional. Subject to chargeback for 120 days (Visa/MC rules).
Max amount Per merchant account limits (typically $50K–$250K per transaction)
Operating hours 24×7 for authorization; batch settlement on banking days
Currency Multi-currency (per Stripe account configuration)
Authorization holds Supported (card authorization hold, 7-day default)
Proof method Stripe charge ID + balance transaction ID
AURA clearing integration Transitional. Card chargeback window overlaps with AURA dispute window. AURA’s reserve absorbs this risk.

Instruction mapping:

Finality definition: Card settlement is never truly final from AURA’s perspective. Chargebacks can occur up to 120 days after the original transaction. AURA’s clearinghouse treats card settlement as provisional finality and manages the gap through:

  1. Risk margin held for the full chargeback window (not just AURA’s dispute window)
  2. Higher risk margin percentage for card payments vs. RTP/stablecoin (priced into the risk model)
  3. Chargeback notifications from Stripe trigger AURA dispute creation (auto-filed)

Why transitional: Cards add 1.5–3% in network fees, introduce chargeback risk that AURA must absorb, and create finality ambiguity. As participants adopt wallet-based settlement (RTP, stablecoin), card volume migrates. The adapter remains for backward compatibility with principals who have not onboarded to direct settlement methods.

4.3.5 Bank Transfer (ACH — US)

Attribute Value
Settlement speed Same-day ACH (by 4:45 PM ET cutoff) or Next-day
Finality Provisional. ACH returns possible for 2 banking days (unauthorized: 60 days).
Max amount $1,000,000 per transaction (same-day ACH limit)
Operating hours Banking days, with 3 same-day processing windows
Currency USD only
Authorization holds Not natively supported. AURA manages holds at market layer.
Proof method ACH trace number + NACHA return/acknowledgment
AURA clearing integration Suitable for B2B with negotiated terms (Net 30/60). Not recommended for real-time consumer transactions.

Instruction mapping:

Finality definition: ACH settlement is provisional until the return window closes (2 banking days for most returns; 60 days for unauthorized transactions). AURA’s clearing lifecycle remains at settling until the return window passes, then transitions to settled. For B2B profiles with Net 30/60 terms, this delay is acceptable. For retail profiles, ACH is not recommended as a primary rail.

4.3.6 Manual / Offline (MVP)

Attribute Value
Settlement speed Operator-confirmed
Finality Operator-attested
Proof method Operator signature on settlement confirmation

For development, testing, and edge cases where no automated rail is available. The clearing lifecycle pauses at settling until an operator manually confirms settlement and provides a signed proof. Used in MVP for bootstrapping before production rail integrations are live.

5. Rail Routing

5.1 Routing Logic

The Settlement Orchestrator routes instructions to rails based on:

  1. Payment method on agreed terms. The offer’s payment_terms.accepted_methods and the Scout’s selected method determine the primary rail.
  2. Rail capabilities. Amount limits, currency support, jurisdiction — if the primary rail can’t handle the instruction, fallback routing applies.
  3. Market Profile preferences. The active profile may prefer specific rails (e.g., B2B profile prefers RTP over card).
  4. Participant connectivity. Both parties must have settlement wallets compatible with the selected rail.

5.2 Routing Table

Payment Method (agreed terms) Primary Rail Fallback Rail Fallback Condition
rtp RTP FedNow Participant bank not on RTP network
stablecoin_usdc Stablecoin (USDC) None N/A — wallet-to-wallet
programmatic_wallet Stablecoin (USDC) RTP Wallet provider supports bank settlement
bank_transfer ACH (US) / SEPA (EU) RTP / FedNow Amount below real-time limit and urgency warrants
card Stripe None N/A — card-specific
trade_credit Internal ledger Bank transfer at term expiry N/A

5.3 Fallback and Retry

If a rail submission fails:

  1. Transient failure (network timeout, rate limit) → Retry same rail with exponential backoff. Max 3 retries. Idempotency key ensures no duplicate settlement.
  2. Permanent failure on primary rail (insufficient funds, account closed, compliance hold) → Do NOT fallback to another rail. Return failure to clearing lifecycle. Clearing status → failed. Exception notification to both parties.
  3. Rail outage (entire rail unavailable) → If fallback rail is configured and both parties have compatible wallets, route to fallback. If no fallback, hold in settling state and alert operator.

Design principle: Never silently switch rails. If a fallback is used, both parties are notified and the clearing record reflects the actual rail used, not the originally intended rail.

6. Exception Handling

6.1 Exception Types

Exception Trigger Clearing Impact Resolution
Settlement timeout No proof within clearing window settling → failed Retry or cancel. Buyer funds returned if held.
Amount mismatch Proof amount ≠ instruction amount Proof rejected New instruction with correct amount, or exception escalation
Partial settlement Rail settles less than instructed (if permitted) Clearing remains at settling Supplementary instruction for remainder
Rail rejection Rail rejects instruction (compliance, account issue) settling → failed Structured rejection reason returned to clearinghouse
Duplicate proof Same idempotency key, different proof details Second proof rejected Alert — potential fraud or rail error
Orphaned instruction Instruction submitted, rail confirms, but AURA didn’t receive proof Clearing stuck at settling Reconciliation process (Section 7) detects and resolves
Chargeback (card only) Card network reverses settlement Dispute auto-created AURA dispute process; reserve covers payout
ACH return (ACH only) Originator bank returns ACH debit settled → settling (regression) Re-collect via alternative method or cancel transaction

6.2 Exception Escalation

Level 0: Automatic retry (transient failures, idempotent)
Level 1: Automatic fallback (rail outage, if configured)
Level 2: Operator alert (permanent failure, amount mismatch)
Level 3: Manual intervention (orphaned instruction, suspected fraud)
Level 4: Regulatory escalation (compliance hold, sanctions flag)

6.3 Clearing Lifecycle on Failure

When settlement fails and cannot be retried:

settling → failed → authorized (rollback)

The clearing lifecycle returns to authorized state. From there:

The reserve manager does NOT hold margin on a failed settlement. Margin is held only after settled is achieved.

7. Reconciliation

7.1 Reconciliation Model

AURA reconciles with each rail at three frequencies:

Frequency Purpose Mechanic
Real-time Confirm each settlement as proof arrives Proof verification (Section 3.3)
Intraday Detect orphaned instructions, missing proofs, amount discrepancies Automated comparison: AURA instructions vs. rail confirmations
End-of-day Comprehensive balance reconciliation AURA escrow balance vs. rail-reported balance

7.2 Intraday Reconciliation

Every 15 minutes (configurable per rail), the reconciliation engine:

  1. Queries all instructions in submitted status older than the rail’s expected confirmation latency
  2. Polls the rail for status on each outstanding instruction (via adapter.status())
  3. Matches rail responses to AURA instructions by idempotency_key
  4. Detects discrepancies:
    • Instruction submitted but rail has no record → orphaned instruction → escalate
    • Rail confirmed but AURA has no proof → missing proof → request proof replay
    • Amount confirmed ≠ amount instructed → amount mismatch → escalate
    • Rail reports failure that AURA didn’t receive → update clearing status

7.3 End-of-Day Reconciliation

At the configured settlement day boundary (default: 00:00 UTC):

  1. Aggregate all confirmed settlements for the day per rail
  2. Compare total settled amount with rail’s settlement report / bank statement
  3. Identify discrepancies at the aggregate level (net position mismatch)
  4. Break resolution: If discrepancies exist, drill down to individual instructions to find the break
  5. Report reconciliation status to operator dashboard

7.4 Reconciliation Record

Every reconciliation run produces a signed record:

{
  "reconciliation_id": "rec_01HXYZ...",
  "rail": "rtp_us",
  "period": {
    "start": "2026-04-13T00:00:00.000Z",
    "end": "2026-04-13T23:59:59.999Z"
  },
  "summary": {
    "instructions_submitted": 1247,
    "instructions_confirmed": 1245,
    "instructions_failed": 2,
    "instructions_pending": 0,
    "total_collected": "487329.50",
    "total_disbursed": "412185.25",
    "total_refunded": "3150.00",
    "total_fees": "12187.50",
    "net_position": "59806.75",
    "rail_reported_position": "59806.75",
    "discrepancy": "0.00",
    "status": "balanced"
  },
  "breaks": [],
  "signed_by": "core_ed25519_key",
  "signature": "sig_rec_01HXYZ..."
}

7.5 Break Resolution

When a reconciliation discrepancy is detected:

  1. Automatic resolution (within tolerance, typically ≤$0.01 per transaction for rounding): adjust via rounding entry in reserve ledger
  2. Investigation (above tolerance): operator alert with full instruction chain for each discrepant transaction
  3. Escalation (persistent breaks): halt new instructions to affected rail until resolved
  4. Regulatory reporting: breaks above regulatory threshold (configurable per jurisdiction) generate compliance notifications

8. Security

8.1 Transport Security

All communication between AURA and settlement rails uses mutual TLS (mTLS). Both parties authenticate with X.509 certificates. Certificate rotation follows the rail’s published schedule.

For stablecoin rails, the “transport” is the blockchain itself. Security is cryptographic (private key custody, transaction signing) rather than channel-based.

8.2 Instruction Integrity

Settlement instructions are signed by Core’s Ed25519 key (Section 2.4). Rails verify the signature before executing. A tampered instruction fails verification and is rejected.

The signing key is distinct from Core’s session/offer signing key. Key separation ensures that compromise of one function does not compromise settlement authority.

8.3 Proof Integrity

Proofs of settlement are verified per Section 3.3. AURA maintains a registry of each rail’s public keys and certificate chains. Key rotation is handled via the public_key_reference URL with a trust-on-first-use (TOFU) model, upgraded to certificate pinning for production rails.

8.4 Key Management

Key Purpose Storage Rotation
Core settlement signing key Sign settlement instructions HSM (FIPS 140-2 Level 3) Annual, with 30-day overlap
Rail verification keys Verify proofs of settlement Key registry (pinned) Per rail’s schedule
mTLS client certificate Authenticate to rail API HSM Per rail’s requirements
Smart contract deployer key Deploy/upgrade escrow contracts HSM, multi-sig (2-of-3) On contract upgrade only
Smart contract operator key Execute escrow operations HSM Quarterly

8.5 Fraud Detection Signals

The Settlement Orchestrator emits signals to the risk engine when anomalous patterns are detected:

Signal Trigger Risk Impact
rapid_settlement_velocity Multiple settlements for same principal in short window Elevated scout_risk_score
rail_mismatch_pattern Repeated fallback routing for same participant Investigate account setup
proof_latency_anomaly Settlement confirmation significantly slower than rail’s SLA Monitor rail health
amount_boundary_clustering Transactions clustering just below rail or reporting thresholds Potential structuring — regulatory flag
cross_rail_arbitrage Same principal settling via different rails for similar transactions Monitor for regulatory avoidance

9. Rail Onboarding

9.1 Integration Checklist

When onboarding a new settlement rail:

  1. Capability declaration. Complete the capabilities JSON (Section 4.2) — settlement speed, finality type, amount limits, currencies, operating hours, proof method.
  2. Adapter implementation. Implement the SettlementRailAdapter interface (Section 4.1) — submit, status, cancel, verify, capabilities.
  3. Finality definition. Document precisely when a settlement is irrevocable on this rail. Map to AURA’s settling → settled transition condition.
  4. Proof format. Define the proof of settlement structure. Implement verification in the adapter.
  5. Exception mapping. Map the rail’s error codes and failure modes to AURA’s exception types (Section 6.1).
  6. Reconciliation integration. Implement the polling/webhook mechanism for intraday reconciliation.
  7. Security setup. Exchange certificates (mTLS), publish verification keys, configure key rotation schedule.
  8. Sandbox testing. End-to-end test in sandbox: submit → confirm → verify → reconcile. Include failure scenarios.
  9. Amount/currency validation. Verify limits match capabilities declaration. Test boundary conditions.
  10. Regulatory review. Document which regulatory framework governs this rail. Confirm AURA’s participation requirements (licenses, registrations, bank relationships).

9.2 Certification

A rail adapter is certified for production when:

10. Relationship to Existing Architecture

10.1 CLEARINGHOUSE.md

This document specifies the external interface that CLEARINGHOUSE.md Section 3.4 (Settlement Orchestrator) uses. The orchestrator calls the rail adapter; this document defines what the adapter does.

Clearinghouse component Settlement Rail interaction
Settlement Orchestrator Submits instructions, receives proofs
Reserve Manager Margin hold/release instructions are internal (no rail interaction unless on-chain)
Clearing Lifecycle Manager Transitions settling → settled on proof verification
Custody Adapter Layer Maps to rail adapter for fund-holding operations

10.2 PROTOCOL_SPECIFICATION.md

Protocol section Settlement Rail relevance
Section 10.7 (Clearinghouse Settlement) Settlement flow triggers instruction submission
Section 13.6 (Settlement Security) HSM and key management requirements from this document
Section 3.2.8 (Settlement Wallet) Wallet registration maps to rail_account_reference
Section 14 (API Reference) Clearing status endpoint reflects rail proof status

10.3 MARKET_PROFILES.md

Market Profiles determine which rails are available and preferred:

11. Open Questions

Version History

Date Change
2026-04-13 v1.0 Initial architecture. Settlement instruction contract, proof of settlement model, 6 rail adapters (RTP, FedNow, stablecoin USDC, card/Stripe, ACH, manual), rail routing, exception handling, reconciliation procedures, security model, rail onboarding checklist. Driven by DEC-045.

Document History

Version Date Changes
1.1 2026-04-14 Added version header, protocol reference updated to v2.2.
1.0 2026-04-13 Initial settlement rail architecture — instruction contract, proof model, 6 adapters, routing, reconciliation. DEC-045.