Banking reference architecture — EMENA

How a regulated EMENA bank deploys Operayde to satisfy SAMA, DORA, and PDPL obligations without letting prompt or model data leave the datacentre.

Regulatory context

An EMENA-domiciled bank operates under overlapping, non-negotiable regimes. SAMA's Cybersecurity Framework and its Cloud Computing Regulatory Framework constrain where regulated workloads may run and demand full audit traceability. DORA, in force since 17 January 2025, imposes ICT third-party risk register obligations and a five-year retention on incident evidence. Saudi Arabia's PDPL adds a data-residency floor: personal data of KSA residents cannot leave the Kingdom without a transfer mechanism the Authority accepts. Operayde is deployed as a customer-hosted appliance specifically so all three regimes can be satisfied by topology, not by contract.

Architecture

The bank installs an Operayde appliance in each production datacentre — typically Riyadh and Jeddah for KSA workloads, mirrored for DR. Each appliance runs the full inference and policy stack: workspace-runtime for vLLM-compatible model serving and RAG, appliance-gateway for local ak_... key auth and OPA policy evaluation, and audit-emitter for the tamper-evident event chain. Nothing in this loop crosses the bank's WAN boundary — prompts, model responses, embeddings and audit records all persist on-appliance.

The bank's applications (loan-decision engines, KYC copilots, treasury research assistants) call the appliance gateway on the local subnet. The appliance forwards only two classes of traffic outbound over a reverse tunnel to Operayde's central plane: fleet telemetry (health, version, hash of the current policy bundle) and Merkle roots of the daily audit chain. Neither carries prompt content.

Data residency

Every model call is evaluated against operayde.residency before it reaches an inference backend. The virtual key attached to the application encodes the allowed regions; a request whose target region falls outside that set is denied at the gateway boundary:

package operayde.residency
 
import rego.v1
 
default allow := false
 
# --- Virtual-key path (Gateway) ---
allow if {
    input.source == "gateway"
    some region in input.params.virtual_key.residency
    region == input.ctx.region
}
 
reason := "region not in allowed residency" if {
    not allow
}

For a KSA-issued key the residency list is ["sa-central"]; any attempt to route to an EU or US-hosted model is denied with the region not in allowed residency reason, logged, and surfaced on the tenant's safety-posture page.

Audit evidence

Every gateway invocation emits a Merkle-linked event into audit.events. The chain is hash-linked (prev_hash → hash) and signed with an Ed25519 key that never leaves the appliance. A loan-decision LLM query looks like this on the wire:

{
  "event_id": "01JC7B8F3E9K2Z1H5X6Q4M0R8N",
  "prev_hash": "b1946ac92492d2347c6235b4d2611184c3e2b1f6f5b3f5a1d3f2e1e4c9d8a7b6",
  "hash":      "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
  "signature": "MEUCIQDwZ...base64url-Ed25519...4Kg==",
  "actor":     { "subject": "loan-engine@prod", "realm": "tenant:bank-riyadh" },
  "tenant_id": "bank-riyadh",
  "action":    "gateway.inference",
  "resource_uri": "model://claude-sonnet-4-6",
  "outcome_status": "ok",
  "occurred_at": "2026-07-13T09:41:22.148Z"
}

The Merkle root of each day's chain is co-signed and pushed to Operayde's central plane, so the bank retains an independently verifiable proof of completeness even if the appliance is later seized or repurposed.

How this maps to the regulations

Requirement	Operayde surface	Evidence
SAMA CSF 3.3.14 — third-party risk & data location	Appliance topology; residency OPA rule	Daily attestation bundle; `residency.rego` in policy bundle
DORA Art. 28 — ICT third-party register & five-year retention	Fleet control plane record + audit chain	Signed Merkle root per day; `audit.merkle_daily` export
PDPL Art. 29 — cross-border transfer prohibition	Virtual-key `residency` field; gateway enforcement	Denied events with `region not in allowed residency` reason

Deployment topology

The Operayde control plane never receives prompt or response data. Its only ingress from the appliance is a mutually-authenticated reverse tunnel carrying (a) fleet health/version and (b) daily Merkle roots. Operator sessions from Operayde staff into the appliance are gated by cosign-signed OPA policy and require MFA step-up every five minutes of privileged work.