How It Works

Your systems stay. Proof becomes part of them.

EpositBox integrates with your existing applications and infrastructure to connect identity, custody, lineage, and verification, without requiring you to replace the systems you depend on.

0
Master keys held by EpositBox
3
Independently permissioned planes
<15 min
Target evidence-package generation
6+ yrs
Records that outlive the application
~6 min
To answer an evidence request, versus a 3–5 day baseline
60–90 days
Fixed-scope pilot to proof

01 / The flow

Capture → Hash & Sign → Encrypt → Store → Audit Chain.

Every record follows the same path. The first three steps happen inside your environment, so nothing readable ever leaves it. Open any step for detail.

  1. 01

    Capture at the point of creation

    A stateless connector reads from your source systems through authenticated APIs, at the moment a trade, consent, claim, document, CDR or AI decision is made. It doesn’t change your application or sit in your decision path.

    • Historical back-load plus incremental, event-driven capture
    • Tags entity, jurisdiction, matter, tenant and record type at ingestion
    • Works with REST, FHIR / X12, ISO 20022, BSS / OSS and CDR feeds
    • Read-only: your systems keep running exactly as today
  2. 02
  3. 03
  4. 04
  5. 05

02 / The three-plane trust model

No single environment, including ours, contains everything.

STRINGS splits what’s needed to reconstruct a record across independently permissioned planes, joined by a private bridge that only ever carries ciphertext and hashes. Tap the info icons for detail.

Customer tenancy

Your environment

Identity, keys, plaintext and runtime stay under your control.

  • Your VPC

    Your applications

  • Stateless

    Local connector

  • BYOK / KYOK

    Your HSM & keys

  • IdP

    Your identity

Private Link bridge
  • Encrypted payloads
  • Hashes & receipts
  • Evidence queries & proofs
  • No raw data
  • No master keys
Two more planes, ciphertext only

EpositBox custody

Even EpositBox cannot decrypt your data, and neither plane is useful on its own.

  • Plane 1

    Permissioned blockchain store

  • Plane 2

    Separate index

  • mTLS

    Custody API

  • SIEM

    Audit ledger

What this means in practice: a breach of your application yields no readable data from the custody plane. A subpoena served on EpositBox yields only ciphertext. A ransomware event leaves the sealed history intact for restoration and response.

03 / The engine

ZKIAM™: zero-knowledge identity and access, under every module.

ZKIAM™ is EpositBox’s patented engine. It decides who and what can touch a sealed record, and makes that decision provable without ever exposing the record itself.

No standing privilege

Nothing to steal in advance

Access is granted per call and proven per call. No standing admin rights wait to be phished.

No shared credentials

Service identity, every time

Mutual TLS and service-identity checks on every request. Each call is attributable to a named workload.

No human path

No one browses the data

There’s no console path to plaintext, which closes off insider misuse and credential theft, the dominant breach routes.

Proof without exposure

Verify, don’t reveal

A third party can confirm a record existed, was unaltered and was accessed lawfully without seeing its contents.

Five properties, built in from the first record.

Blockchain-enhanced security

Risk & overhead reduction

Machine-to-machine access

Version control & recovery

Granular access + full audit trail

04 / How proof works

Getting data in is half the job. Getting proof out is the point.

When an examiner letter, a litigation hold, a breach clock or a counterparty dispute arrives, STRINGS turns sealed history into an evidence package anyone can check independently.

01 · Trigger

Seal on demand

When an inquiry, alert, incident or legal hold starts, the affected records are frozen immediately, before anyone can change them.

02 · Assemble

Scoped retrieval

Filter by entity, jurisdiction, matter, tenant or record type, all tagged at capture, and pull exact versions with their full access history.

03 · Package

Signed evidence pack

A time-ordered, tamper-evident package generated in minutes, not reconstructed over weeks from systems nobody remembers how to run.

04 · Verify

Independent check

The recipient recomputes hashes and checks signatures and the chain themselves. Disclosure is scoped and read-only, and the keys stay with you.

STRINGS is tamper-evident, not tamper-proof: it makes any alteration or deletion detectable rather than physically preventing it.

05 / Integration in practice

A familiar API. An uncommon level of proof.

Your application makes ordinary REST calls to the local connector inside your environment. The connector seals the record before it reaches EpositBox, so the custody API only ever receives ciphertext, a hash and a signature. The same call seals an AI decision record.

  • No model or app changes. A stateless, read-only connector reads from your source systems through authenticated APIs.
  • Signed receipts. Each write returns a pointer, version, audit ID and timestamp you can store alongside the source record.
  • Tagged at capture. Entity, jurisdiction, matter and record type are attached as metadata and drive retrieval later.
  • Verifiable output. Proof bundles are hash-checkable by any third party.
# 1 · Your app → local connector (inside your VPC)
POST https://connector.internal/v1/records
{
  "tenant": "acme-bank-eu",
  "schema": "trade.order.v3",
  "tags": { "entity": "EU-SA", "jurisdiction": "FR", "retention": "7y" },
  "payload": { … }   // plaintext never leaves your VPC
}

# Connector → EpositBox custody API (mTLS, Private Link)
POST https://api.epositbox.com/v1/records
{
  "tenant": "acme-bank-eu",
  "ciphertext": "AES256-GCM:9f2c…e81a",
  "hash": "sha256:4b1d…77c0",
  "signature": "sig:customer-hsm:k-2026-03:…",
  "key_ref": "kyok://hsm/eu-1/k-2026-03"  // a reference, never the key
}

Go deeper

Where it runs, how long it lasts, and how to start.

Your cloud, your region, your keys. STRINGS works alongside your current platforms and doesn’t replace any of them.

Residency

Your region of choice

US, EU, UK or APAC. Data doesn’t move across regions without your approval. Dedicated single-tenant deployments are available for high-sensitivity workloads.

Integration

Fits your existing tools

REST and mTLS, FHIR R4 and X12 for healthcare, ISO 20022 for payments, and BSS / OSS and CDR feeds for carriers. The audit stream goes into Splunk, QRadar, Sentinel or Chronicle.

Validated

FS-validated architecture

Validated on the IBM Cloud for Financial Services ISV landing zone.

IBM Cloud for FSAWS / GovCloudMicrosoft Azure / Azure GovernmentGoogle CloudOracle CloudPrivate cloud & on-prem connectorKubernetesHyperledger Fabric

See it work in two minutes.

Seal a record, tamper with it, and watch the proof catch the change.

Try Demo

Stop attesting. Start proving.

Talk to our team about pilot scope, which STRINGS modules fit your obligations, and how proof gets generated on day one.

Get a Demo