Skip to main content

OpenFin8

Consent-First Open Finance: Every Jurisdiction, One Platform.

Products

Every service this vertical ships, each owning its own data and API surface. Click any card for its full dossier - use cases, architecture, business rules.

SDKs

Typed facades over every service API - the only supported integration surface.

Security pillars

OpenFin8 inherits the Sentin8 security model by construction - the consent ledger, the recipient registry, and every jurisdiction adapter run behind the platform's authorization pipeline, tenant isolation, and post-quantum TLS.

01

No consent, no data

Every provider route passes the consent middleware (valid, unexpired, scope-covered) on top of row-level security; revocation stops serving on the very next call - structurally, no bypass exists.

02

Two ledgers, one truth per side

The provider's grant ledger and the recipient's consent registry live in separate tenants; no cross-tenant SQL ever. Either institution may run any technology - the only contract is standards-based OAuth.

03

Data minimization by construction

Responses are projected to the granted CSDF clusters before serialization - narrowed by scope, product category, and requested fields. Unknown scopes grant nothing.

04

One kernel, zero forks

The entire implementation lives in openfin8-core, shared byte-for-byte. Each country adapter contributes its Profile and registration data - adding a market is configuration, not a port.

05

Licensed specs, never published

The FDX API specification is licensed and never committed; each adapter's published spec carries OpenFin8-owned routes only, enforced by a CI drift guard. Customers supply their licensed copy.

Composed on the Sentin8 platform

OpenFin8 contains no platform infrastructure of its own - identity, events, storage, workflows, and scheduling come from the platform services.