Skip to content

Reference scenarios

Target audience: Solution Architects, Enterprise Architects, CISOs, Business Stakeholders

Reading time: 20 minutes

Prerequisites: Entity reference, Relationships and runtime flow

Introduction

The deployment organization model is general by design. The same set of twelve entities composes solutions for problems that, on the surface, appear unrelated: governing card production with multiple embossing providers, controlling cryptographic operations performed by an outsourced collections processor, and operating cryptography across multiple regulatory jurisdictions.

This page works through three reference scenarios. Each scenario shows the conceptual modeling — applications, contexts, actors, assets, grants, constraints — that materializes the solution. The scenarios are deliberately representative of common enterprise problems, drawn from real industry patterns.

Scenario Industry pattern Key challenge
Card issuance with multiple providers Banking — payment cards Multiple third-party embossing vendors, each with bounded access to cardholder data
BPO collections processing Banking — outsourced operations A BPO operates on customer data without ever receiving cleartext bulk files
Multi-jurisdiction regulatory reporting Multinational enterprise Cryptographic operations governed by different regulatory regimes per jurisdiction

Scenario 1: Card issuance with multiple providers

Context

A bank issues physical cards through two embossing providers: VISA and AMEX. Each provider must decrypt cardholder data only for the cards it physically produces, only during the agreed batch window, and never beyond that scope.

In a traditional model, the bank would deliver the cardholder data file to each provider, encrypted with a key that has been pre-shared. This creates several problems:

  • The provider holds key material outside the bank's control domain
  • Revocation requires bilateral coordination
  • Audit depends on what the provider reports
  • A provider compromise exposes cardholder data the provider was not actively producing
  • The bank cannot enforce per-batch or time-window restrictions cryptographically

Modeling with ANKASecure©

flowchart TB
    subgraph BANK["🏦 Bank — Tenant: Card Operations"]
        APP["Application: Card Issuance"]

        subgraph VCTX["Exchange Context: Embossing — VISA"]
            direction TB
            VACT["Actor: visa-embossing-actor"]
            VGRANT["Grant: decrypt<br/>+ single-use<br/>+ batch-scoped<br/>+ time window"]
            VASSET["Asset: embossing-key-visa"]
            VACT --> VGRANT --> VASSET
        end

        subgraph ACTX["Exchange Context: Embossing — AMEX"]
            direction TB
            AACT["Actor: amex-embossing-actor"]
            AGRANT["Grant: decrypt<br/>+ single-use<br/>+ batch-scoped<br/>+ time window"]
            AASSET["Asset: embossing-key-amex"]
            AACT --> AGRANT --> AASSET
        end

        APP --> VCTX
        APP --> ACTX
    end

    VISA["🏢 VISA<br/>embossing system"]
    AMEX["🏢 AMEX<br/>embossing system"]

    VISA -.->|invokes decrypt| VACT
    AMEX -.->|invokes decrypt| AACT

    style BANK fill:#e8f4f8,stroke:#1a5276,stroke-width:2px
    style APP fill:#d5f5e3,stroke:#1e8449
    style VCTX fill:#d6eaf8,stroke:#2980b9
    style ACTX fill:#fdebd0,stroke:#d68910
    style VISA fill:#fadbd8,stroke:#c0392b
    style AMEX fill:#fadbd8,stroke:#c0392b

Entity composition

Application

  • Card Issuance — the business domain that owns the card production process

Exchange Contexts

  • Embossing — VISA: OUTBOUND exchange with VISA, sensitivity RESTRICTED
  • Embossing — AMEX: OUTBOUND exchange with AMEX, sensitivity RESTRICTED

Cryptographic Actors

  • visa-embossing-actor: belongs to Card Issuance, represents VISA's embossing system
  • amex-embossing-actor: belongs to Card Issuance, represents AMEX's embossing system

Cryptographic Assets

  • embossing-key-visa: symmetric data-encryption key used to protect VISA-bound batches
  • embossing-key-amex: symmetric data-encryption key used to protect AMEX-bound batches

Capability Grants

VISA grant:

Actor:            visa-embossing-actor
Capability:       decrypt
Asset:            embossing-key-visa
Exchange Context: Embossing — VISA
Constraints:
  - Single-use per batch identifier
  - Batch-scoped (decrypts only records tagged with the active batch_id)
  - Time window: 2026-04-26T00:00Z to 2026-04-26T06:00Z
  - Rate limit: 50,000 ops / hour

AMEX grant:

Actor:            amex-embossing-actor
Capability:       decrypt
Asset:            embossing-key-amex
Exchange Context: Embossing — AMEX
Constraints:
  - Single-use per batch identifier
  - Batch-scoped (independent batch_id namespace)
  - Time window: 2026-04-26T02:00Z to 2026-04-26T08:00Z
  - Rate limit: 30,000 ops / hour

Resulting properties

Property Outcome
Provider isolation VISA cannot decrypt AMEX-bound data; AMEX cannot decrypt VISA-bound data
Key non-exposure Neither provider receives raw key material; both invoke decrypt capabilities
Bounded usage Each provider is constrained to its own batch and its own time window
Independent revocation Suspending VISA's grant does not affect AMEX's operations
Auditable evidence Every decryption produces an audit event linking actor, batch, capability, and outcome

The model scales naturally to additional providers (a third issuer joins the program), to additional capabilities (verification of provider-signed receipts), and to additional jurisdictions (per-country exchange contexts), without architectural change.

Scenario 2: BPO collections processing

Context

A bank outsources delinquent customer collections to a BPO (Business Process Outsourcer). The BPO operates on customer data — names, contact details, account balances — to perform outreach. Today, this means the bank decrypts portfolios into bulk CSV files and transfers them to the BPO via SFTP.

This model has several structural problems:

  • The bank loses visibility into how the data is used once it arrives at the BPO
  • Files persist on BPO infrastructure indefinitely
  • A BPO breach exposes the entire transferred portfolio
  • Revocation requires coordinating data deletion across BPO systems
  • Audit depends on BPO self-reporting

Modeling with ANKASecure©

The model replaces the bulk file transfer with mediated, per-record cryptographic invocations. The BPO never receives a bulk plaintext file; it receives the right to invoke the bank's decrypt capability under controlled conditions, record by record.

flowchart TB
    subgraph BANK["🏦 Bank — Tenant: Collections Operations"]
        APP["Application: Collections Outsourcing"]

        subgraph BPOCTX["Exchange Context: BPO Collections — Alpha"]
            direction TB
            BPOACT["Actor: bpo-alpha-collections-actor"]
            BPOGRANT["Grant: decrypt<br/>+ rate-limited<br/>+ business-hours only<br/>+ per-record scope<br/>+ contextual mTLS"]
            BPOASSET["Asset: collections-data-key-2026Q2"]
            BPOACT --> BPOGRANT --> BPOASSET
        end

        APP --> BPOCTX
    end

    BPO["🏭 BPO Alpha<br/>collections agents"]

    BPO -.->|invokes decrypt<br/>per record| BPOACT

    style BANK fill:#e8f4f8,stroke:#1a5276,stroke-width:2px
    style APP fill:#d5f5e3,stroke:#1e8449
    style BPOCTX fill:#fadbd8,stroke:#c0392b
    style BPO fill:#fdebd0,stroke:#d68910

Entity composition

Application

  • Collections Outsourcing — the business domain owning the collections workflow

Exchange Context

  • BPO Collections — Alpha: OUTBOUND exchange with BPO Alpha, sensitivity RESTRICTED, status ACTIVE for the duration of the contract

Cryptographic Actor

  • bpo-alpha-collections-actor: belongs to Collections Outsourcing, represents BPO Alpha's processing system, type EXTERNAL_PARTY

Cryptographic Asset

  • collections-data-key-2026Q2: symmetric encryption key protecting the quarterly collections portfolio data

Capability Grant

Actor:            bpo-alpha-collections-actor
Capability:       decrypt
Asset:            collections-data-key-2026Q2
Exchange Context: BPO Collections — Alpha
Constraints:
  - Rate limit: 500 ops / hour (matches expected agent throughput)
  - Time window: business hours only (Mon-Fri 08:00-18:00 local)
  - Per-record scope (one decryption per call, no bulk operations)
  - Contextual: mTLS with BPO's client certificate from approved CA
  - Auto-revoke on: 100 consecutive denials in 1 hour (anomaly signal)

How a typical workflow runs

sequenceDiagram
    participant AGENT as BPO agent system
    participant CCP as ANKASecure©
    participant HSM as Bank HSM
    participant AUD as Bank audit

    Note over AGENT: Agent opens customer record #4521
    AGENT->>CCP: decrypt(asset=collections-data-key-2026Q2, record=4521)
    CCP->>CCP: Evaluate grant + context + constraints
    Note over CCP: Within business hours ✓<br/>Under rate limit ✓<br/>mTLS valid ✓
    CCP->>HSM: Execute decrypt
    HSM-->>CCP: Plaintext for record 4521
    CCP->>AUD: Log: actor, record-id, timestamp, allow
    CCP-->>AGENT: Plaintext for record 4521 only
    Note over AGENT: Agent makes outreach call<br/>Plaintext is ephemeral

Resulting properties

Property Outcome
Zero bulk transfer The bank never delivers a CSV file. Each record is an individual invocation
Per-record audit Every customer record accessed produces an audit event with the record identifier
Time-bound access Operations outside business hours are denied automatically
Behavioral revocation Anomalous patterns (rate spikes, denial bursts) auto-revoke the grant
Immediate termination Contract termination = grant revocation. No file deletion across BPO infrastructure required
Sovereignty preserved The portfolio key never leaves the bank's HSM. The BPO operates on capabilities, not data

This model is what ANKASecure© refers to as the paradigm shift from sharing keys to sharing capabilities — the underlying principle is described in Cryptographic sovereignty.

Scenario 3: Multi-jurisdiction regulatory reporting

Context

A multinational financial institution operates in multiple regulatory jurisdictions: the European Union (under DORA, GDPR, eIDAS 2), the United States (under SOX, NIST), and South America (under regional data protection laws). Each jurisdiction imposes specific cryptographic requirements:

  • EU regulators require ETSI-aligned signatures and post-quantum readiness for long-retention data
  • US federal entities require NIST FIPS 203/204/205 algorithms
  • Regional jurisdictions require local data residency and sovereign cryptographic operations

The institution must produce regulatory reports to each jurisdiction's authority, signed with cryptographic mechanisms that satisfy local rules — without architecting three separate platforms.

Modeling with ANKASecure©

The model uses three Exchange Contexts (one per jurisdiction), each with its own actor, asset, and policy regime. The Application — Regulatory Reporting — is the unified business domain.

flowchart TB
    subgraph DEPLOY["🏛️ Deployment: Multinational"]
        subgraph TENANT["Tenant: Regulatory & Compliance"]
            APP["Application: Regulatory Reporting"]

            subgraph EUCTX["Exchange Context: Reporting — EU"]
                direction TB
                EUACT["Actor: eu-regulatory-reporter"]
                EUGRANT["Grant: sign<br/>+ ETSI-aligned policy<br/>+ daily window"]
                EUASSET["Asset: eu-reporting-key (ML-DSA-87 + RSA-PSS hybrid)"]
                EUACT --> EUGRANT --> EUASSET
            end

            subgraph USCTX["Exchange Context: Reporting — US"]
                direction TB
                USACT["Actor: us-regulatory-reporter"]
                USGRANT["Grant: sign<br/>+ NIST FIPS policy<br/>+ daily window"]
                USASSET["Asset: us-reporting-key (ML-DSA-87)"]
                USACT --> USGRANT --> USASSET
            end

            subgraph SACTX["Exchange Context: Reporting — South America"]
                direction TB
                SAACT["Actor: sa-regulatory-reporter"]
                SAGRANT["Grant: sign<br/>+ regional policy<br/>+ residency-bound"]
                SAASSET["Asset: sa-reporting-key (RSA-4096 + ML-DSA-65)"]
                SAACT --> SAGRANT --> SAASSET
            end

            APP --> EUCTX
            APP --> USCTX
            APP --> SACTX
        end
    end

    EUREG["📋 EU regulator"]
    USREG["📋 US regulator"]
    SAREG["📋 SA regulators"]

    EUACT -.->|signed report| EUREG
    USACT -.->|signed report| USREG
    SAACT -.->|signed report| SAREG

    style DEPLOY fill:#e8f4f8,stroke:#1a5276,stroke-width:2px
    style TENANT fill:#d6eaf8,stroke:#2980b9
    style APP fill:#d5f5e3,stroke:#1e8449
    style EUCTX fill:#fdebd0,stroke:#d68910
    style USCTX fill:#e8daef,stroke:#7d3c98
    style SACTX fill:#fadbd8,stroke:#c0392b

Why this composition works

Single Application, multiple contexts. The business workflow is the same: produce a regulatory report and submit it. The cryptographic governance differs per jurisdiction. By modeling jurisdictional governance in the Exchange Context (not the Application), the business logic remains unified while the cryptographic policies remain jurisdiction-specific.

Policies attached at multiple levels. A Policy at deployment level defines the universal cryptographic baseline (FIPS posture, hybrid requirement, minimum security level). Policies at Exchange Context level refine those for each jurisdiction (ETSI signature schemes for EU, FIPS-only for US, residency-bound for SA).

Independent assets per jurisdiction. Each jurisdiction's signing key is a separate Cryptographic Asset, governed by its own lifecycle policy and rotation schedule. A key compromise or rotation in one jurisdiction does not cascade to the others.

Independent actors per jurisdiction. A single business workflow may invoke up to three actors in sequence — one per jurisdiction it must report to — using credentials and policies appropriate to each. Actor separation also produces audit clarity: which jurisdiction received which signed report, when, with which key.

Resulting properties

Property Outcome
Single business application Regulatory Reporting is one Application, not three
Jurisdictional independence Each Exchange Context governs its own algorithms, policies, lifecycle
Policy inheritance Deployment baseline → tenant refinement → context override
PQC adoption per jurisdiction EU adopts hybrid ML-DSA + RSA today; US adopts pure ML-DSA; SA continues with classical+PQC hybrid until local mandate matures
Residency compliance Each jurisdiction's keys are tagged with residency constraints; HSM placement reflects them
Audit segregation Reports to each jurisdiction produce audit events tagged with the corresponding context — supporting jurisdiction-specific compliance reporting

This scenario illustrates a model property worth highlighting: the Exchange Context is the substrate that lets multi-jurisdiction governance compose cleanly. Without it, the same business logic would have to fragment into multiple applications or multiple tenants — neither of which is faithful to the actual organizational structure.

Cross-scenario observations

Observation Why it matters
The same twelve entities compose all three scenarios One model serves internal integrations, third-party exchanges, and multi-jurisdiction governance
The Exchange Context is the differentiator A KMS without business interaction modeling cannot represent these scenarios with the same fidelity
Capability Grants make authorization atomic Each grant can be revoked, suspended, or audited as a single decision — supporting granular operational governance
Constraint Policies translate business rules to cryptographic enforcement Time windows, batch scopes, rate limits, contextual requirements — all enforced at the control plane, not in application code
Audit emits the same shape across all scenarios Compliance reporting becomes a uniform query across heterogeneous business workflows

Beyond these scenarios

The model is not limited to financial services. The same conceptual composition supports:

  • Healthcare data exchange (clinical labs, insurers, research consortia)
  • Government inter-agency data sharing
  • Telecommunications partner data exchange (roaming, MVNO billing, IPX interconnection)
  • Retail and supply chain (EDI with suppliers, federated loyalty programs)
  • SaaS multi-tenancy with enterprise BYOK customers

For the broader applicability of the cryptographic sovereignty model, see Cryptographic sovereignty.

Next steps