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.

The tenant declares one Exchange Context for the business purpose, Card Issuance. The context names no direction and no counterparty. Each directed relationship with a provider is a Cryptographic Exchange in that context, and each Exchange owns the grants of every network that flows in that direction: the bank's batch job encrypting and the provider decrypting, or the provider encrypting results and the batch job decrypting them. A two-way flow with a provider is therefore two Exchanges in the same context, one per direction.

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

        subgraph CTX["Exchange Context: Card Issuance (RESTRICTED)"]
            direction LR

            subgraph PAOUT["Exchange: Card Issuance to Provider A (OUTBOUND)"]
                direction TB
                VOUTG["VISA — card-visa-batch ENCRYPT<br/>provider-a-embossing-actor DECRYPT<br/>embossing-key-visa · window + usage cap + rate"]
                MOUTG["MC — card-mc-batch ENCRYPT<br/>provider-a-embossing-actor DECRYPT<br/>embossing-key-mc · window + usage cap + rate"]
            end

            subgraph PAIN["Exchange: Provider A to Card Issuance (INBOUND)"]
                direction TB
                VING["VISA — provider-a-embossing-actor ENCRYPT<br/>card-visa-batch DECRYPT<br/>embossing-results-key-visa · window + rate"]
                MING["MC — provider-a-embossing-actor ENCRYPT<br/>card-mc-batch DECRYPT<br/>embossing-results-key-mc · window + rate"]
            end

            subgraph PBOUT["Exchange: Card Issuance to Provider B (OUTBOUND)"]
                direction TB
                AOUTG["AMEX — card-amex-batch ENCRYPT<br/>provider-b-embossing-actor DECRYPT<br/>embossing-key-amex · window + usage cap + rate"]
            end

            subgraph PBIN["Exchange: Provider B to Card Issuance (INBOUND)"]
                direction TB
                AING["AMEX — provider-b-embossing-actor ENCRYPT<br/>card-amex-batch DECRYPT<br/>embossing-results-key-amex · window + rate"]
            end
        end

        APP --> CTX
    end

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

    PROVIDA -.->|"invokes decrypt (VISA, MC)"| PAOUT
    PROVIDA -.->|"invokes encrypt results (VISA, MC)"| PAIN
    PROVIDB -.->|"invokes decrypt (AMEX)"| PBOUT
    PROVIDB -.->|"invokes encrypt results (AMEX)"| PBIN

    style BANK fill:#e8f4f8,stroke:#1a5276,stroke-width:2px
    style APP fill:#d5f5e3,stroke:#1e8449
    style CTX fill:#f4f6f7,stroke:#566573
    style PAOUT fill:#fff,stroke:#2980b9
    style PAIN fill:#fff,stroke:#2980b9,stroke-dasharray:4 4
    style PBOUT fill:#fff,stroke:#d68910
    style PBIN fill:#fff,stroke:#d68910,stroke-dasharray:4 4
    style PROVIDA fill:#fadbd8,stroke:#c0392b
    style PROVIDB fill:#fadbd8,stroke:#c0392b

Solid borders = outbound Exchanges (bank encrypts, provider decrypts). Dashed borders = inbound Exchanges (provider encrypts, bank decrypts). All four Exchanges live in the one Card Issuance context.

Entity composition

Application

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

Exchange Context

Cryptographic Exchanges

Each Exchange is activated, suspended, resumed and revoked as one unit, and every grant it owns authorizes only while it is ACTIVE. Network isolation comes from the per-network keys and the per-network grants inside each Exchange; the context groups the whole card production process.

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), two in each of Provider A's Exchanges.
• 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, two Exchanges)

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: Card Issuance
  Exchange:         Card Issuance to Provider A (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: Card Issuance
  Exchange:         Card Issuance to Provider A (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: Card Issuance
  Exchange:         Provider A to Card Issuance (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: Card Issuance
  Exchange:         Provider A to Card Issuance (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, two Exchanges)

Grant 5 — AMEX outbound decrypt:
  Actor:            provider-b-embossing-actor
  Capabilities:     ["DECRYPT"]
  Asset:            embossing-key-amex
  Exchange Context: Card Issuance
  Exchange:         Card Issuance to Provider B (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: Card Issuance
  Exchange:         Provider B to Card Issuance (INBOUND)
  Constraint Policy: embossing-results-amex-2026-04-26
    - validFrom / validUntil, rateLimitPerMinute 100

The batch jobs' grants (ENCRYPT on each outbound key, DECRYPT on each results key) belong to the same Exchanges as the provider grants they pair with, so each Exchange holds both sides of its flow.

Resulting properties

Blast radius by revocation scope:

The model scales naturally to additional networks (a fourth program joins: new keys and grants in the existing Exchanges), additional providers (Provider C handles a regional network: two new Exchanges in the same context), or additional capabilities (signature verification of provider receipts) without architectural change.

In the Basic Demo, the demo-bank tenant provisions this scenario with Gemalto (Thales) as Provider A and IDEMIA as Provider B, in the Exchanges Card Issuance to Gemalto (Thales), Gemalto (Thales) to Card Issuance, Card Issuance to IDEMIA and IDEMIA to Card Issuance. A fifth Exchange, Card Issuance internal, holds the application's own certificate-attestation signing and verification grants.

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: Collections Outsourcing"]
            direction TB

            subgraph BPOEX["Exchange: Collections Outsourcing to BPO Alpha (OUTBOUND)"]
                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
        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:#f4f6f7,stroke:#566573
    style BPOEX fill:#fadbd8,stroke:#c0392b
    style BPO fill:#fdebd0,stroke:#d68910

Entity composition

Application

• Collections Outsourcing — the business domain owning the collections workflow

Exchange Context

• Collections Outsourcing: the business purpose, sensitivity RESTRICTED. It names no direction and no counterparty

Cryptographic Exchange

• Collections Outsourcing to BPO Alpha: OUTBOUND, counterparty BPO Alpha, in the Collections Outsourcing context. It owns BPO Alpha's DECRYPT grant and the paired ENCRYPT grant of the bank's own data issuer (bank-collections-issuer), and stays 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: Collections Outsourcing
Exchange:         Collections Outsourcing to BPO Alpha (OUTBOUND)
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 identity is carried by that credential, not by the transport: a Constraint Policy cannot require actor-level mTLS client-certificate pinning, so do not design an access boundary that depends on one.

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 one Exchange Context for the business purpose, Regulatory Reporting, and one outbound Cryptographic Exchange per jurisdiction's authority in it, each with its own actors, asset, and Constraint Policies. 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 CTX["Exchange Context: Regulatory Reporting (CONFIDENTIAL)"]
                direction LR

                subgraph EUEX["Exchange: Regulatory Reporting to EU Regulator (OUTBOUND)"]
                    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 USEX["Exchange: Regulatory Reporting to US Regulator (OUTBOUND)"]
                    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 SAEX["Exchange: Regulatory Reporting to SA Regulators (OUTBOUND)"]
                    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
            end

            APP --> CTX
        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 CTX fill:#f4f6f7,stroke:#566573
    style EUEX fill:#fdebd0,stroke:#d68910
    style USEX fill:#e8daef,stroke:#7d3c98
    style SAEX fill:#fadbd8,stroke:#c0392b

Why this composition works

Single Application, single business purpose, one Exchange per authority. The business workflow is the same: produce a regulatory report and submit it. The cryptographic governance differs per jurisdiction. The Exchange Context states the business purpose once; each jurisdiction's relationship is its own Exchange, with its own counterparty, grants and lifecycle. The business logic remains unified while the cryptographic rules 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). The Constraint Policies on each jurisdiction's grants refine it (ETSI-aligned daily window for EU, FIPS-aligned daily window for US, residency-bound window 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.

Independent lifecycle per jurisdiction. Suspending the Exchange Regulatory Reporting to US Regulator stops US submissions alone; the EU and SA Exchanges keep authorizing. Suspending the Regulatory Reporting context stops every submission at once.

Resulting properties

This scenario illustrates a model property worth highlighting: the Exchange Context and its Exchanges let multi-jurisdiction governance compose cleanly. The context holds the one business purpose; the Exchanges hold the per-authority relationships. Without them, the same business logic would have to fragment into multiple applications or multiple tenants — neither of which is faithful to the actual organizational structure.

In the Basic Demo, the demo-bank tenant provisions this scenario in the Exchanges Regulatory Reporting to EU Regulator, Regulatory Reporting to US Regulator and Regulatory Reporting to SA Regulators, each also holding the regulator's VERIFY grant, plus Regulatory Reporting internal for the long-retention archive key.

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

The Basic Demo provisions one tenant per vertical — insurance, healthcare, government, retail, telecommunications, energy and manufacturing — beside the bank that carries the three scenarios above, each modeled with the same twelve entities: one Exchange Context per business application, and in each application one Cryptographic Exchange per counterparty or peer application and direction. See Basic Demo tenants^*.

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.