Changelog

Honesty fixes — agent learning and held-payment emails

• Held-payment emails now hide compliance-review detail — a structuring/SAR hold reads as a neutral "under review" line, the same wording the API and webhooks use — and name the true sanctions cause: a payment held because the agent has no wallet on file no longer says "the counterparty could not be screened". Every held email ends with "Sign in to the console to see the full reason"; the console still shows the full, specific reason to your team.
• A multi-reason hold now lists every reason recorded on the payment (strictest first, up to five). A wallet address shown in an email is shortened; the payment reference stays whole. The auto-reject window in the copy is read from configuration, not a fixed "72 hours".
• Agent copy now reflects what the code does: a trust score only erodes on violations — there is no automatic upward or "earned" path — and a person on your team approves a new agent in the console before it governs on its own. A shared cross-partner reputation layer remains on the roadmap, not live today. Field names and decisions are unchanged; only wording changed.

Stablecoins first-class — USDC, USDT, EURC, PYUSD and DAI on by default

• New agents and new tenants may now pay in USDC, USDT, EURC, PYUSD and DAI by default, alongside EUR/USD/GBP. Existing tenants that already allowed USDC gain EURC, PYUSD and DAI automatically; existing agents are never widened. Volatile assets (ETH, BTC, …) stay opt-in, per agent and per tenant.
• Amounts are never truncated. Every supported asset — including DAI's 18 decimals — is stored and returned at full precision. Send a high-precision amount as a JSON string. Payment amount is returned as a string quantised to the asset's own decimals.
• Limits, budgets and thresholds work in stablecoins: a stablecoin is valued at its fixed peg (USDC/USDT/PYUSD → USD, EURC → EUR; DAI at its registry peg) before it is compared to a limit set in another currency, and the asset, amount and peg used are recorded in the decision evidence. A depeg is not detected in this release (a known follow-up).
• An approval in one currency does not cover a payment in a different one — including a stablecoin — unless the approval lists that currency (unchanged behaviour, now pinned).
• New: add or rotate an agent's crypto wallet at POST /v1/agents/{agent_id}/wallet. The new wallet is sanctions-screened immediately and the change is held if it cannot be screened against fresh data; a listed wallet is refused and the agent suspended. Requires the new explicit-only wallet:rotate scope or a console session — never an agent's payments key.
• x402 micropayments now screen BOTH the paying agent's wallet AND the destination against the full OFAC SDN list (the same list the payment pipeline uses) and apply the currency allowlist and precision check — the former short hard-coded address list is gone. x402 fails closed exactly like a normal payment.
• Crypto payments keep every existing protection: wallet screening, held when sanctions data is missing or stale, a list hit blocks and suspends, country checks always, and a card/bank payment with no wallet is not held for a wallet check it does not need.
• Honesty fixes. Revvyn no longer implies conformance with any regulatory framework on a served surface. GET /v1/compliance/check per-framework detail now reads as reference-only (e.g. MiCA/PSD2); GET /v1/compliance/frameworks labels each framework enforced (OFAC sanctions, FATF Travel-Rule data) or informational; the per-agent compliance record does the same; and a fabricated FX-spread figure was removed. Field names are unchanged; only these values changed.

Every rule is checked — the strictest outcome applies

• If a payment breaks more than one rule, the strictest outcome now applies — a payment that should be refused is refused, not just held.

Approvals — a bad approval can never be waved through by another hold

• A payment that cites an unknown, revoked, expired or not-yet-valid approval can never be approved, even if another check only held it. Every way out of a hold re-checks the cited approval. This changes outcomes only for payments that cite an approval.

Payment approvals — limit what an agent may pay

• New: payment-approval objects at /v1/payment-approvals (create, read, list, narrow, revoke). An approval records what an agent is approved to pay (amount range, currency, validity window); creating, narrowing, or revoking one needs the new approvals:write scope or a console session.
• New: optional approval_id on POST /v1/payments and POST /v1/governance/evaluate. When a payment cites an approval, Revvyn checks — before you move money — that the payment is within it. Omit it and the payment behaves exactly as before.
• Behaviour: an amount or currency outside the approval holds the payment for your review; an unknown, revoked, expired, or not-yet-valid approval blocks it. A payment never consumes an approval on /evaluate.
• Narrowing is shrink-only (a widening is refused); revocation is immediate and final. A payment held against an approval cannot be approved once that approval is revoked.
• Security: the approvals:write permission is explicit-only — a full-access or payments key never holds it — and a key carrying it can only be minted in the console by a signed-in person, never by another API key. Only a signed-in person in the console can rotate or re-enable such a key (or the key rotating itself). So an agent can never widen its own limits — by minting a key, or by rotating one to get a fresh secret.

Consistent review wording everywhere

• Improved: consistent wording for payments under review across all API responses and webhooks.

Per-payment evidence record

• New: per-payment evidence pack (JSON and PDF) — what Revvyn decided, which checks ran, and how to verify the signed verdict.

Standard wording for reviewed payments on API-key reads; SAR records console-only

• Payment reasons and audit details for reviewed payments now use standard wording.
• New reason code PAYMENT_UNDER_REVIEW.
• Audit entries returned to API keys no longer include hash fields; use /v1/audit/verify to check integrity.
• SAR records are available in the console only.
• SAR statistics are available in the console only.

Per-account idempotency keys; partner external reference stored

• Idempotency keys are now scoped per account and environment.
• The partner's external reference is now stored with the payment.
• Idempotency documentation corrected.

Incident reports account-scoped; operator-only diagnostics; placeholder rail webhooks return 501

• Incident reports now require authentication and are visible only to the account that filed them.
• A deep health diagnostics endpoint and an agent wiring endpoint are now operator-only.
• The placeholder Stripe and Bridge rail webhook endpoints now return 501 (not enabled) until those integrations are live.

Operator-only agent diagnostics; autonomy report scoped to your account

• Several agent-diagnostics endpoints are now operator-only. They return platform-wide agent internals, so they are restricted to platform operators; a partner API key receives an admin-required response.
• The agent autonomy report now returns only your own account's metrics. Platform-wide fields are returned as null with their keys kept, so integrations that read these fields keep working; the platform-wide values themselves are no longer provided to partner accounts.
• Routine housekeeping removed internal liveness records from shared operational memory, so the self-description confidence distribution and the entity relationship graph's per-agent memory counts now reflect real memories only.

Shared-memory filter (extended) — more partner views

• The shared-memory filter now also applies to these partner views: introspection views; the contradictions list; memory lineage, supersession chains, and recent supersessions; the agent learning curve, preferences, retrospectives, and self-description; and the entity relationship graph. In these views, a shared operational-memory item that references a specific registered party — including your own account — is not shown, and its identifier does not appear in a graph, chain, or count; your account's own items are unaffected. Response shapes are unchanged; only which shared items appear is refined.

Shared-memory filter — knowledge, compliance, and lifecycle views

• A shared-memory filter applies to these partner views: knowledge memory detail and its linked items; agent and entity disagreements; memory retention and its replay; archive simulation and restore; contradiction handling; the compliance (CCO) dashboards; the governance assistant; regulatory observations; and the lifecycle views (overdue, chargeback risk, settlement times, insights). In these views, a shared operational-memory item that references a specific registered party — including your own account — is not shown; your account's own items are unaffected. Response shapes are unchanged; only which shared items appear is refined.
• The lifecycle views (overdue, chargeback risk, settlement times, insights) return your account's own items.

Regulatory observations — platform-level items only

• Regulatory observations now contain only platform-level regulatory items. GET /v1/regulatory/horizon/observations returns RegulatoryHorizon's platform-level regulatory observations (policy_violation_regulatory and compliance_gap) and no account-specific content; the response shape is unchanged.

Honesty pass — standing and posture, feedback and replay labels

• Standing and posture are shown as separate things. The Agent Governed Live screen now labels each agent with a read-only standing word — Suspended, Inactive, Restricted, Reduced, New or Established — projected from the agent's own state (verification, activity, trust level, and whether it has a scored track record) in the SAME order the governance pipeline applies its agent-level checks. A new agent_standing field is added to GET /v1/agents (additive; existing fields and values unchanged; derived server-side, not read back into any decision). Standing is separate from a payment's posture (governed / held / blocked): a well-standing agent's payment can still be held or blocked, and a new agent's would-allow payments are held for a person to confirm until you approve the agent. (Every agent is unscored today — Established appears only once settled-history scoring is enabled.)
• The new-agent review is shown as its own step. When a payment is held only by the post-pipeline new-agent review, that hold now appears as its own step on the live screen, so a held payment no longer reads as an all-green pipeline. Per-stage markers are driven by each stage's own recorded action.
• Feedback copy corrected. POST /v1/payments/{id}/feedback and GET /v1/intelligence/feedback-stats previously implied feedback was fed back into thresholds and trust scoring. It is not: feedback is recorded for your own review only, held in process memory (not retained across restarts), and is not wired into thresholds, trust scoring or policy. The copy now says so.
• Replay label corrected. In GET /v1/payments/{id}/replay, the per-step signals_consumed object is renamed payment_inputs: it carries the payment's own request fields (amount, currency, corridor, beneficiary), the same on every step — not a per-agent record of signals consumed.
• Hold-reason wording. The hold_reason description now states its mechanism: the explanation is drawn from a fixed partner-copy table keyed by the reason code, so it carries that code and its mapped wording — not a counterparty name, wallet address, risk score or internal threshold. It is present on the live evaluate response; the re-fetched stored verdict (GET /v1/governance/verdict/{id}) returns the byte-identical signed bytes only, so hold_reason is absent there.

Evaluate — a derived, unsigned hold_reason on the signed verdict

• The signed-verdict response from POST /v1/governance/evaluate now carries an additive, optional hold_reason object so you can see why a non-ALLOW verdict was held or blocked: reason_code (the decisive governance reason, identical to what POST /v1/payments records for the same decision), an optional floor_reason (set when the new-agent review floor also applied), and an optional explanation (the same partner-facing wording the escalation review cards use, or null when the code has no dedicated wording). It is null when the decision is ALLOW. It is DERIVED and UNSIGNED — it is not part of claims and is not covered by the verdict signature, so a verifier must rely on the signed claims. The signed claims, canonical field set and signature are unchanged. Server-derived from the governance result only; never set by request input. It never contains a counterparty name, wallet address, risk score or internal threshold. [Correction 2026-10-06: precise mechanism — the explanation is drawn from a fixed partner-copy table keyed by the reason code, so it carries that code and its mapped wording and nothing from request input; it is present only on the live evaluate response and is absent on the re-fetched stored verdict (GET /v1/governance/verdict).]

Evaluate-only quotes — sandbox provenance excluded from the learning lists

• The agent-signal and bus-event streams (GET /v1/learning/signals, GET /v1/learning/events) now exclude provenance rows produced while governing an evaluate-only quote (POST /v1/governance/evaluate), so a sandbox preview never appears in — or counts toward — your live signal/event stream. A quote's own rows remain retrievable by id, labelled with a new is_evaluate_only field (true for a quote). The field is additive; existing fields and values are unchanged. Server-determined from the evaluate-only status of the run; never set by request input.

Agent-standing stage — display name

• Display values for the first pipeline stage changed from "KYA" / "Know Your Agent" to "Agent standing" across the console, ops console, operator assistant and API display fields (e.g. the agent roster name/role, the knowledge-graph display name, and the GET /v1/payments/{id}/explain remediation hint). Field names, reason codes and the internal agent id (kya) are unchanged — only human-readable display text. The stage checks the agent is registered to the partner and assesses its standing; it does not perform a cryptographic identity check.
• Agent passport and onboarding text now describe a registration and standing credential; field names unchanged.
• Compliance report (GET /v1/agents/{id}/compliance): the PSD2 framework status now reads not_performed instead of pending — Revvyn performs no holder strong-customer-authentication, so "pending" wrongly implied a check in progress. The reputation attestation (GET /v1/reputation/{id}/export) is now described as a SHA-256 fingerprint of the record, not a cryptographic signature. Field names and the signature value are unchanged.
• Private preview: the SLA page and legal SLA/support text now state that no service-level commitment applies during the private preview (internal engineering latency targets are labelled as such). Platform-health latency_p95 reads not_measured; the compliance report and the complete-export manifest now describe the audit trail as hash_present_not_verified (a hash is present; re-run chain verification via GET /v1/audit/verify-chain) rather than "verified". Field names unchanged.
• Legal attestation (GET /v1/legal/attestation) is described as plain statements, not signed; the PSD2 line now states SCA step-up is requested via escalation (no production issuer integrated). The data export (GET /v1/export/complete) adds a portability_export_supported field and clarifies that gdpr_compliant indicates the export follows the GDPR Article 20 data-portability format, not a legal certification. Field names and values unchanged.

Approval rate — now verdict-based

• The approval_rate_pct field on GET /v1/analytics is now derived from the final governance verdict — a payment counts as approved when it was allowed automatically or released by a reviewer — not from payment lifecycle status. Payments still awaiting review are excluded from the rate and reported separately in the new approval_pending_count field. When no payments were decided in the window the field is null (shown as —), never 0%. Field name unchanged; effective 2026-09-28.

Sanctions coverage — explicit boundary

• The sanctions report (GET /v1/reports/sanctions) and the regulator evidence pack (GET /v1/reports/regulator-pack) now return an explicit not_checked field — alongside the screened OFAC SDN crypto-wallet list, they state the lists and check types Revvyn does not yet screen, so the coverage boundary is explicit rather than inferred from silence. Additive, non-breaking; existing fields unchanged.
• New read-only endpoint GET /v1/platform/sdn-state reports the live OFAC SDN screening-set state (loaded / fresh / address count / publication version), computed from the screening data — no hand-typed status.

Intelligence Layer

• Transaction Intelligence Engine with anomaly detection
• 7 fraud typology detectors (BEC, romance, investment, ATO, mule, APP, invoice)
• External data-source adapters present as sandbox stubs (not live-screened); the live sanctions screen is OFAC SDN crypto-wallet addresses
• Geographic intelligence with corridor risk scoring
• Explainability engine with counterfactual analysis
• Simulation sandbox for policy what-if analysis
• Agent Message Bus for inter-agent communication
• Agent Memory (persistent learned state)

Enterprise Features

• Governance coverage for SEPA, SWIFT, card, ACH, RTP and stablecoin rails (USDC, USDT, EURC, PYUSD, DAI); Revvyn governs these payments, it does not move funds
• Enforced controls: OFAC SDN sanctions screening and the FATF Travel-Rule data ESCALATE; other frameworks (PSD2, MiCA, GDPR, FCA) are mapped for reference only and not assessed by Revvyn
• Compliance reporting with CSV export
• Batch payments (up to 100 per batch)
• Scheduled payments with pre-approval
• Webhook system with HMAC-SHA256 signing
• API key management (create/rotate/revoke)
• Billing metering and invoice generation
• Idempotency support (X-Idempotency-Key)
• Circuit breaker pattern for rail failover

Operations Suite

• Operations dashboard at /ops with morning summary and live feed
• Fraud intelligence at /ops/fraud
• Compliance view at /ops/compliance
• Agent Intelligence Center at /ops/agents
• KYA Deep Dive at /ops/agents/kya
• Payment detail with explainability at /ops/payment

Partner Experience

• Self-service onboarding portal at /onboard
• Partner dashboard at /partner/dashboard
• Partner documentation at /partner/docs
• SLA page, changelog, integration guides

Infrastructure

• CI/CD with GitHub Actions (lint, security, test, Docker)
• Production Dockerfile (multi-stage, non-root)
• Render Blueprint deployment
• Structured JSON error responses with X-Request-ID
• Rate limiting with X-RateLimit headers
• Dark/light theme system

Core Platform

• 6-agent governance pipeline (KYA, Orchestrator, Governance, Control, Execution, Audit) [Correction 2026-09-29: these six units are deterministic pipeline STAGES, not autonomous agents.]
• Multi-tenant architecture with API key authentication
• PostgreSQL async backend with SQLAlchemy 2.0
• 11 payment rails (sandbox implementations)
• Policy engine (sanctions, limits, KYC, yield) [Correction 2026-09-29: no KYC or yield provider is connected in production; KYC is recorded as NOT_CHECKED.]
• Append-only, hash-chained audit trail (7-year retention) [Correction 2026-09-29: the 7-year figure is a retention TARGET stamped at write; automated deletion after 7 years is not yet implemented.]
• Network security (Tor/VPN/IP velocity)
• HITL approval flow
• Kill switch emergency halt
• Governance dashboard with fraud scenario walkthroughs
• Stripe integration (sandbox) — the Stripe charge path was later removed (2026-09-25); Revvyn is governance-only on every rail (ADR-010) and never holds or moves funds.