Built fail-closed, isolated, and auditable.

• No custody. We move the instruction, your customer's bank moves the money.
• Fail-closed by default at every boundary. When something is ambiguous or unreachable, the system stops.
• Isolated at the database, not just the application. No tenant scope set means zero rows.
• Authenticated cryptography throughout. No unauthenticated modes in production.
• Not a bank, not a PSD2 AISP or PISP. You keep your existing regulatory posture.

Passwords are hashed with scrypt at strong cost parameters, verified in constant time, and checked against known-breached password lists. Two-factor is TOTP, with used codes consumed so they can't be replayed inside their window, plus ten single-use backup codes hashed at rest. Machine-to-machine API keys carry 256 bits of entropy and are stored only as a hash, shown once and never again. Login attempts are throttled per identity and per source IP, shared across every instance so a lockout can't be dodged by hitting another replica.

Sessions are opaque server-side tokens, hashed at rest, in an HttpOnly, SameSite=Strict, Secure cookie scoped per subdomain. Every session has an absolute maximum lifetime of eight hours and a separate thirty-minute inactivity timeout, whichever expires first. Each authenticated request re-validates the session and slides the inactivity window forward, never past the eight-hour cap, so a stale or idle session can't linger. Users can view their active sessions and revoke them, administrators can terminate a user's sessions, and enabling or disabling two-factor ends all other sessions. Sensitive changes require a fresh two-factor code rather than trusting the existing session.

Tenant scope is derived from the authenticated caller, never read from the request body or query, and checked against both independently. Isolation is enforced by genuine Postgres row-level security in FORCE mode, which applies even to the table owner, on every tenant table. With no scope set, a query returns zero rows by default. The platform refuses to start in production if the database role could bypass that rule, so the isolation can't be silently switched off. Within a company, roles are a fail-closed allow-list: a new mutating route is denied to read-only users until it's explicitly permitted.

Sensitive fields, credentials, and signing keys are encrypted with AES-256-GCM at the application layer, before anything reaches the database, so stored bytes are ciphertext even to a full-database read. Each ciphertext is bound to its exact table, column, tenant, and row, so a stolen value can't be relocated to another column or tenant and decrypted. Keys carry an embedded identifier so old data still decrypts through a rotation, and an unknown key identifier throws rather than silently mis-decrypting. The audit-signing key is held separately from the field-encryption key, so one leaked key can't also forge the log.

Database connections require verified TLS, and the server refuses to start if TLS is disabled or set not to verify. Outbound traffic to banks and webhook endpoints is HTTPS-only, validates the certificate, is pinned to the pre-resolved address, follows no redirects, and caps the response size. One deliberate exception exists, a single bank certificate-revocation list fetched over plain HTTP and then verified independently by signature.

Online certificate revocation checking and Encrypted Client Hello are not wired; we rely on CA-chain validation plus certificate pinning. Both are Level 3 items.

Each bank channel uses the real cryptography the bank requires. SOAP channels use signed and encrypted payloads with RSA-SHA256 signatures, and inbound signatures are certificate-pinned and fail closed on a signer mismatch. EBICS uses DOM-bound XML signatures with anti-signature-wrapping checks. SFTP encrypts to the bank's key with recipient fingerprint pinning and verifies the host key against a pinned fingerprint, refusing an unpinned host in production. Certificate pins carry expiry warnings and fail closed when a pin lapses.

Where a bank still mandates an older primitive, we use it, wrapped in extra integrity and pinning. We don't present the underlying primitive as our choice.

With our built-in approvals, a host-to-host payment is held and released at a single guarded point, evaluated under a row lock so two approvals can't race. The person who created a payment can't approve it, the same person can't approve twice, and the approver must be named in the policy, not merely hold the role. A fresh two-factor code is required at approval. A payment that needs approval with no eligible approver is refused at dispatch rather than parked indefinitely. Platforms that run their own external approval process keep that dual-control in their own system, and we deliver only what they release.

Payments are delivered straight to the customer's bank over their own channel. We never return the signed payment file to the caller. That closes off using the platform as a signing service for instructions that weren't approved: a caller gets a status reference back, never a signed file they could submit elsewhere.

Every outbound URL is checked against an allow-list and a structural SSRF guard that rejects loopback, private, link-local, and cloud-metadata addresses, along with obfuscated IP literals. Each resolved address is range-checked, the connection is pinned to the validated address to defeat DNS-rebinding between check and connect, and no redirects are followed. Webhook destinations are re-checked at delivery time, not just at registration.

Permitted file types and size ceilings are defined and enforced, with an ingest cap on inbound files. Compressed files are checked against decompression-bomb expansion. Submitted filenames are validated against path traversal, and account identifiers are masked in any filename that gets served or logged.

Responses carry an explicit Content-Security-Policy, frame-ancestors set to none, nosniff, a referrer policy, cross-origin isolation headers, and HSTS with preload in production. There's no JSONP anywhere, authenticated responses are JSON only, and client assets are served same-origin from local bundles. HTTP parameter pollution is rejected, and CSRF protection is bound to the session rather than a bare double-submit, which defeats sibling-subdomain cookie planting.

We don't use the __Host- cookie prefix. That's deliberate: a multi-tenant platform needs domain-scoped cookies across subdomains, which the prefix forbids, so isolation rests on Domain, Secure, and SameSite=Strict instead. Level 2 item, resolved by design.

Every state change is written to a journal the database itself refuses to update or delete, enforced by a trigger that fires even for the table owner. Each entry is HMAC-hash-chained to the one before it, keyed per company, so any modification, deletion, insertion, or reorder is detectable, and a live endpoint re-walks the chain and reports the first inconsistent entry. The signing key comes from the key provider, not the database, so an attacker with database write access still can't recompute the chain. We're explicit about the boundary: this is tamper-evidence within our trust boundary, not an external timestamping service.

Sensitive data is inventoried and classified, and an approver's national ID number is encrypted, masked to the last four on every read, and resolved in the clear only transiently at file-build time, never logged. Logs are scrubbed by both key name and value shape, and metrics carry no tenant identifiers or personal data. Retention is classified per data type, with erasure supported for the right-to-be-forgotten, and responses are set not to cache sensitive content.

The platform treats any ambiguous environment as production and fails closed. It won't boot without verified database TLS, an independent audit key of sufficient strength, and a non-bypassable isolation role. Debug modes and directory listings are off in production, the HTTP TRACE method is unsupported, and monitoring endpoints are gated behind a token. Input is validated with strict schemas against mass-assignment and type confusion, a software bill of materials is generated in CI, dependencies are audited at a blocking threshold, and third-party CI actions are pinned to specific commits.