Security Overview

403 Finance, Inc., a Delaware corporation with offices at 1111B S Governors Ave, Ste 92573, Dover, DE 19904, USA ("403 Finance," "we," "us"), provides Transmute (the "Service"), a hosted, usage-metered API that converts and normalizes financial messages between SWIFT MT and ISO 20022 formats. This Security Overview explains how the Service is built and operated so that a prospective customer's security, risk, and vendor-due-diligence teams can evaluate us. It uses the defined terms of our Terms of Service — Service, Message Content, Output, Usage Metadata, and Customer — which have the meanings given there.

1. Purpose and Status

(a) Informational document. This Overview is provided for information only. It describes our security architecture and practices as of the date above. It is not a contract, a warranty, or an amendment to any agreement, and it does not create any commitment enforceable against us. Our binding security obligations to you live in the Data Processing Addendum (DPA) — specifically the technical and organizational measures in DPA Annex II — which is incorporated into the Terms of Service. Where this Overview and the DPA differ, the DPA governs.

(b) Living document. Security is a continuing program, not a fixed state. We update our controls as the Service evolves, and we revise this Overview accordingly. The "Last updated" date reflects the current version.

2. Architecture: Stateless by Design

(a) Request-scoped processing. The Service is stateless by design. For a synchronous conversion, your Message Content exists only in the memory of the process that is serving your request; the Output is returned to you, and the payload is not written to durable storage. Message bodies are never persisted and never logged. The database stores metadata only — message type, message size, processing duration, request timestamp, response status, and warning counts — the records we need to meter usage, enforce quotas, and support you.

(b) Why this bounds a breach. Because we hold no archive of Message Content or Output, the blast radius of any worst-case event is bounded by construction rather than by policy. A compromise of the database would expose metadata and credential hashes — not customer message content. A compromise of the logging surface would expose no message content, because the logger is structurally body-free (see §7). The disclosure scope of a worst-case event is therefore limited to at most the two enumerated exceptions in §3 — the batch jobs in flight or within their ≤24-hour retention window, plus idempotency-cache entries within their 24-hour window. There is no historical payload data to expose, because none is kept.

3. The Two Exceptions

Exactly two mechanisms hold anything derived from a payload, and each is itself controlled. These match the license grant in the Terms of Service and the measures in the DPA.

(a) Idempotency response cache. So that a safely retried request does not double-process, the Service caches a response keyed by a hash of the request body — the raw body is never stored. Entries carry a 24-hour maximum time-to-live and expire unconditionally. In production this cache runs on an encrypted volume.

(b) Encrypted batch job store. Asynchronous batch jobs store inputs and results only as AES-256-GCM ciphertext. Batch inputs are purged at the completion of each item; results default to a one-hour retention and are configurable by you from one minute up to a twenty-four-hour maximum; a sweeper enforces expiry on a fixed cadence; and you can purge on demand via DELETE /v1/jobs/{id}.

4. Encryption

(a) In transit. All external traffic is TLS-encrypted, edge-to-origin included, with a minimum of TLS 1.2. Our edge runs in Full (strict) mode against an origin certificate; we never terminate to plaintext between edge and origin.

(b) At rest. The only payload-bearing database columns — the batch job input and result columns — hold AES-256-GCM ciphertext and nothing else.

(c) Credentials. API keys and OAuth client secrets are SHA-256-hashed at rest and shown exactly once at creation; a lost secret cannot be recovered, only replaced. Webhook signing secrets are sealed with the same AES-256-GCM keyring used for batch data.

(d) Webhook integrity. Outbound webhook payloads are signed with HMAC-SHA256 over a timestamp and body (t=<unix>,v1=<hex>), verified in constant time, with a five-minute tolerance window for replay protection.

5. Data Residency

(a) EU hosting. The Service runs on Cloudflare Workers and Containers in the WEUR (Frankfurt) region, with metadata and encrypted batch ciphertext stored in Neon Postgres on AWS eu-central-1 (Frankfurt). EU-only processing is a product commitment.

(b) Honest transfer disclosure. Day-to-day administrative access to the production environment occurs from the United Kingdom by our operator; for EU personal data, that access is covered by the EU–UK adequacy decision. EU Standard Contractual Clauses remain in place under the DPA as a safeguard for any residual administrative access from the United States. We do not claim that data never leaves the EU, and we make no multi-region or US-region availability claim.

6. Access Control and Authentication

(a) API keys. Keys are high-entropy secrets, hashed at rest, scoped per route, and verified in constant time so that verification never reveals whether a key prefix exists. Rate limits are enforced as a per-tenant aggregate across all keys and OAuth clients, with per-principal fairness controls, so traffic cannot be split across keys to circumvent a limit.

(b) IP allowlisting. Per-credential IP allowlisting is available on request: we can restrict a credential to a set of source networks. Spoofed forwarding headers are ignored unless a trusted proxy is explicitly configured.

(c) OAuth2. Machine-to-machine access uses the OAuth2 client-credentials grant, issuing short-lived ed25519-signed JWTs (15-minute lifetime); client secrets are hashed at rest like API keys.

(d) Portal authentication. The customer portal is passwordless: you sign in through a single-use magic link sent to your account email. The Service stores no portal passwords.

(e) Dedicated administrative surface. Administrative functions are exposed only on a dedicated, identity-authenticated administrative surface, separate from customer API credentials. The customer-credential-authenticated surface remains the metered API alone.

(f) Revocation and audit. Key revocation takes effect in ≤60 seconds (outstanding OAuth tokens expire within 15 minutes); every credential-lifecycle action is written to an append-only audit trail that contains metadata only and never secrets.

7. Engineering Assurance

Security properties are enforced by the build, not merely asserted:

(a) Body-free logging is tested in CI. A source-level contract test (TestLoggingSourceIsBodyFree) proves the request logger cannot reference the request body, and it runs on every change.

(b) Continuous scanning. All parser and conversion attack surfaces are fuzzed nightly and must never panic; govulncheck runs nightly across the full dependency graph; and the full test suite runs nightly under the race detector.

(c) Deterministic, byte-exact testing. Conversions are validated against a byte-exact golden corpus with deterministic warning ordering, and all test data is synthetic — published example IBANs and TEST BICs, never real financial data.

8. Sub-Processors and Vendor Review

(a) Sub-processors. We use a short, disclosed set of sub-processors, published in our Sub-Processor List (maintained under the DPA). No sub-processor receives Message Content or Output at rest other than as described in §3, and no AI or LLM vendor sits in the product path.

(b) Vendor review. We review our sub-processors on at least an annual basis as part of our vendor-management program. Changes to the Sub-Processor List are notified per the DPA, and you may object as provided there.

9. Incident Response and Disclosure

(a) Program. We operate an incident-response process with a documented SEV1–SEV4 severity ladder and defined containment mechanics: API-key revocation in ≤60 seconds, OAuth-token expiry within 15 minutes, job-sealing-key rotation, and on-demand or precautionary batch-payload purge.

(b) Notification. We notify affected customers of an incident affecting their data or service without undue delay; the specific notification windows that bind us are set in the DPA, not in this Overview.

(c) Reporting a vulnerability. Security researchers and customers can report suspected vulnerabilities to security@403fin.io; see our Vulnerability Disclosure Policy for scope and safe-harbor terms.

10. Compliance Posture

(a) Aligned, not certified. The Service is designed in alignment with the SOC 2 Trust Services Criteria. We maintain a formal readiness program anchored by a documented control matrix — every control cites a concrete repository mechanism — and an evidence runbook. We are not SOC 2 certified, audited, or attested, and we hold no ISO 27001 certificate; no observation window has begun. ISO 27001 is tracked as a parallel readiness track on the same evidence base.

(b) Organization size and compensating controls. We are candid that 403 Finance is a small organization; certain controls that larger teams satisfy through segregation of duties are instead satisfied here by architecture and automation: automation-enforced merge gates and CI security tests, an append-only audit trail, and a stateless design that makes least-privilege the default (no historical payload to over-expose). Readiness items that remain open — including a third-party penetration test, centralized log aggregation and alerting, and a business-continuity restore drill — are tracked internally with named owners, and we share current status with customers on request.

11. Self-Hosted Option

For customers who require full data custody, the Service is also available as a self-hosted deployment on your own infrastructure, governed by a separate Enterprise Self-Hosted License Agreement. In that mode, all Message Content, Output, and metadata remain entirely within your environment; license verification is a pure offline function with zero telemetry and no network I/O, so the deployment is air-gap capable and performs no phone-home. Licenses are term-limited and enforced locally by the signed license file's expiry; there is no remote kill or revocation mechanism, because none is needed — your operational continuity during the licensed term never depends on reaching us.

Change History

Back to the Transmute legal center