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 across multiple card networks, 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 1: Card issuance with multiple networks and providers

Context

A bank issues physical cards across three card networks — VISA, Mastercard, and AMEX. Card production is handled by two embossing vendors:

• Provider A produces VISA and Mastercard cards.
• Provider B produces AMEX cards exclusively.

The exchange is bidirectional: the bank sends each provider an encrypted batch file with the cardholder data for that production run; the provider processes the batch, then sends back an encrypted result file confirming production outcomes per card. The bank decrypts the results to reconcile the program.

In a traditional model, each provider would hold a pre-shared key to encrypt and decrypt data independently. This creates compounded problems across three networks and two vendors:

• Providers hold key material outside the bank's control domain
• A compromise at Provider A exposes VISA data, MC data, or both — blast radius is undefined
• Revocation requires bilateral key destruction with no guarantee of completion
• The bank cannot enforce per-network or time-window restrictions cryptographically
• Audit depends entirely on what providers self-report
• The bidirectional flow (provider encrypts results) means the bank must also share a key for inbound data

Modeling with ANKASecure©

The model replaces key sharing with capability grants. Providers never receive key material. They invoke the bank's control plane to decrypt inbound data and to encrypt outbound results. Each card network has independent keys per direction; the physical vendor identity is captured in the actor, not the key.

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

        subgraph PA_SCOPE["Provider A — VISA + MC"]
            direction LR

            subgraph VOUT["Embossing — VISA (OUTBOUND)"]
                direction TB
                PAACT["provider-a-embossing-actor"]
                VDGRANT["Grant: DECRYPT<br/>embossing-key-visa<br/>+ window + usage cap + rate"]
                VASSET["Asset: embossing-key-visa"]
                PAACT --> VDGRANT --> VASSET
            end

            subgraph VIN["Embossing Results — VISA (INBOUND)"]
                direction TB
                PAACT2["provider-a-embossing-actor"]
                VEGRANT["Grant: ENCRYPT<br/>embossing-results-key-visa<br/>+ window + rate"]
                VRASSET["Asset: embossing-results-key-visa"]
                PAACT2 --> VEGRANT --> VRASSET
            end

            subgraph MOUT["Embossing — MC (OUTBOUND)"]
                direction TB
                PAACT3["provider-a-embossing-actor"]
                MDGRANT["Grant: DECRYPT<br/>embossing-key-mc<br/>+ window + usage cap + rate"]
                MASSET["Asset: embossing-key-mc"]
                PAACT3 --> MDGRANT --> MASSET
            end

            subgraph MIN["Embossing Results — MC (INBOUND)"]
                direction TB
                PAACT4["provider-a-embossing-actor"]
                MEGRANT["Grant: ENCRYPT<br/>embossing-results-key-mc<br/>+ window + rate"]
                MRASSET["Asset: embossing-results-key-mc"]
                PAACT4 --> MEGRANT --> MRASSET
            end
        end

        subgraph PB_SCOPE["Provider B — AMEX"]
            direction LR

            subgraph AOUT["Embossing — AMEX (OUTBOUND)"]
                direction TB
                PBACT["provider-b-embossing-actor"]
                ADGRANT["Grant: DECRYPT<br/>embossing-key-amex<br/>+ window + usage cap + rate"]
                AASSET["Asset: embossing-key-amex"]
                PBACT --> ADGRANT --> AASSET
            end

            subgraph AIN["Embossing Results — AMEX (INBOUND)"]
                direction TB
                PBACT2["provider-b-embossing-actor"]
                AEGRANT["Grant: ENCRYPT<br/>embossing-results-key-amex<br/>+ window + rate"]
                ARASSET["Asset: embossing-results-key-amex"]
                PBACT2 --> AEGRANT --> ARASSET
            end
        end

        APP --> PA_SCOPE
        APP --> PB_SCOPE
    end

    PROVIDA["🏢 Provider A system"]
    PROVIDB["🏢 Provider B system"]

    PROVIDA -.->|"invokes decrypt (VISA, MC)"| VDGRANT
    PROVIDA -.->|"invokes decrypt (MC)"| MDGRANT
    PROVIDA -.->|"invokes encrypt results (VISA)"| VEGRANT
    PROVIDA -.->|"invokes encrypt results (MC)"| MEGRANT
    PROVIDB -.->|"invokes decrypt (AMEX)"| ADGRANT
    PROVIDB -.->|"invokes encrypt results (AMEX)"| AEGRANT

    style BANK fill:#e8f4f8,stroke:#1a5276,stroke-width:2px
    style APP fill:#d5f5e3,stroke:#1e8449
    style PA_SCOPE fill:#d6eaf8,stroke:#2980b9
    style PB_SCOPE fill:#fdebd0,stroke:#d68910
    style VOUT fill:#fff,stroke:#2980b9
    style VIN fill:#fff,stroke:#2980b9,stroke-dasharray:4 4
    style MOUT fill:#fff,stroke:#27ae60
    style MIN fill:#fff,stroke:#27ae60,stroke-dasharray:4 4
    style AOUT fill:#fff,stroke:#d68910
    style AIN fill:#fff,stroke:#d68910,stroke-dasharray:4 4
    style PROVIDA fill:#fadbd8,stroke:#c0392b
    style PROVIDB fill:#fadbd8,stroke:#c0392b

Solid borders = outbound contexts (bank encrypts, provider decrypts). Dashed borders = inbound contexts (provider encrypts, bank decrypts).

Entity composition

Application

• Card Issuance — the business domain that owns the card production process across all three networks

Exchange Contexts

Cryptographic Actors

• provider-a-embossing-actor: belongs to Card Issuance, represents Provider A's system; type THIRD_PARTY. Holds four grants (VISA + MC, both directions).
• provider-b-embossing-actor: belongs to Card Issuance, represents Provider B's system; type THIRD_PARTY. Holds two grants (AMEX, both directions).
• card-visa-batch: internal batch job for VISA; type SERVICE. Encrypts outbound + decrypts inbound.
• card-mc-batch: internal batch job for MC; type SERVICE.
• card-amex-batch: internal batch job for AMEX; type SERVICE.

Cryptographic Assets

Capability Grants — Provider A (four grants, one actor)

Each grant names a Constraint Policy, which carries the four dimensions the control plane enforces: a time window, a total usage cap, a per-minute rate limit, and a single-use flag. A production run is bounded by scoping the window to that run and the usage cap to that run's card count, then issuing a fresh policy for the next run — which is how a per-run boundary is expressed with the controls that exist.

Grant 1 — VISA outbound decrypt:
  Actor:            provider-a-embossing-actor
  Capabilities:     ["DECRYPT"]
  Asset:            embossing-key-visa
  Exchange Context: Embossing — VISA (OUTBOUND)
  Constraint Policy: embossing-visa-2026-04-26
    - validFrom / validUntil: 2026-04-26T00:00Z to 06:00Z
    - maxUsage:               50000   (the run's card count, the whole cap)
    - rateLimitPerMinute:     900

Grant 2 — MC outbound decrypt:
  Actor:            provider-a-embossing-actor
  Capabilities:     ["DECRYPT"]
  Asset:            embossing-key-mc
  Exchange Context: Embossing — MC (OUTBOUND)
  Constraint Policy: embossing-mc-2026-04-26
    - validFrom / validUntil: 2026-04-26T01:00Z to 07:00Z
    - maxUsage:               36000
    - rateLimitPerMinute:     600

Grant 3 — VISA inbound encrypt:
  Actor:            provider-a-embossing-actor
  Capabilities:     ["ENCRYPT"]
  Asset:            embossing-results-key-visa
  Exchange Context: Embossing Results — VISA (INBOUND)
  Constraint Policy: embossing-results-visa-2026-04-26
    - validFrom / validUntil: 2026-04-26T06:00Z to 12:00Z
    - rateLimitPerMinute:     100

Grant 4 — MC inbound encrypt:
  Actor:            provider-a-embossing-actor
  Capabilities:     ["ENCRYPT"]
  Asset:            embossing-results-key-mc
  Exchange Context: Embossing Results — MC (INBOUND)
  Constraint Policy: embossing-results-mc-2026-04-26
    - validFrom / validUntil: 2026-04-26T07:00Z to 13:00Z
    - rateLimitPerMinute:     100

Capability Grants — Provider B (two grants)

Grant 5 — AMEX outbound decrypt:
  Actor:            provider-b-embossing-actor
  Capabilities:     ["DECRYPT"]
  Asset:            embossing-key-amex
  Exchange Context: Embossing — AMEX (OUTBOUND)
  Constraint Policy: embossing-amex-2026-04-26
    - validFrom / validUntil, maxUsage 30000, rateLimitPerMinute 500

Grant 6 — AMEX inbound encrypt:
  Actor:            provider-b-embossing-actor
  Capabilities:     ["ENCRYPT"]
  Asset:            embossing-results-key-amex
  Exchange Context: Embossing Results — AMEX (INBOUND)
  Constraint Policy: embossing-results-amex-2026-04-26
    - validFrom / validUntil, rateLimitPerMinute 100

Resulting properties

Blast radius by revocation scope:

The model scales naturally to additional networks (a fourth program joins), additional providers (Provider C handles a regional network), or additional capabilities (signature verification of provider receipts) 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 limit<br/>+ time window<br/>+ usage cap"]
            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 THIRD_PARTY

Cryptographic Asset

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

Capability Grant

Actor:            bpo-alpha-collections-actor
Capabilities:     ["DECRYPT"]
Asset:            collections-data-key-2026Q2
Exchange Context: BPO Collections — Alpha
Constraint Policy: bpo-alpha-2026Q2
  - rateLimitPerMinute:     9        (≈ 500 ops/hour, matching expected agent throughput)
  - validFrom / validUntil: the contract term
  - maxUsage:               250000   (the quarter's portfolio size)
  - revokeOnUse:            false

Two properties of this scenario come from the shape of the API, not from a Constraint Policy:

• One decryption per call. The decrypt endpoint operates on the payload it is given; there is no bulk-export verb for an actor to reach. The absence of a bulk operation is what makes the access per-record — not a BATCH_SCOPE constraint, which does not exist.
• Transport security. Every call is TLS to the edge and the actor authenticates with an OAuth 2.0 client_credentials credential whose secret is rotatable with a grace window. Actor-level mTLS client-certificate pinning is not implemented, and a Constraint Policy cannot require it.

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 time window ✓<br/>Under rate limit ✓<br/>Under usage cap ✓
    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

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

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

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

• For the entity definitions used in these scenarios, see Entity reference.
• For the runtime authorization flow that evaluates each invocation, see Relationships and runtime flow.
• For the broader principle of cryptographic sovereignty in third-party exchange, see Cryptographic sovereignty.