Financial Fraud Auditing & ZK-Receipt Verification

Real-time banking transaction anomaly detection with mathematical proof of computational integrity (HMAC-SHA256) and PCI-DSS compliance

Financial institutions operating core banking ledgers, SWIFT messaging switches, and payment networks face stringent regulatory requirements including PCI-DSS v4.0 (Requirements 3, 6, and 10) and SOX Section 404. Exporting raw transactional ledgers containing Primary Account Numbers (PAN), counterparties, and balances to external cloud providers or AI model APIs violates core confidentiality boundaries.

The Logic-Injection-on-Origin Protocol addresses financial fraud auditing through Cryptographic In-Situ Verification:

1. Confidential Core Execution: Fraud heuristics execute directly within the bank’s sovereign database enclave.
2. Deterministic Egress Enforcement: The Egress Shield automatically strips raw account numbers and transaction IDs.
3. ZK-Receipt Sealing: The Data Node generates an HMAC-SHA256 computational receipt bound to the exact code executed and the ephemeral post-quantum session secret. The consuming agent mathematically verifies that the fraud verdict was generated by the authentic enclave without tampering.

---

Step 1: Implement the Bank Core Enclave

import { LiopServer, PII_PRESETS } from "@nekzus/liop";
import { z } from "zod";

const bankServer = new LiopServer(
  { name: "Bank_Core_Enclave", version: "3.1.0" },
  {
    tokenSlug: "CORE_BANK",
    port: 15021,
    security: {
      forbiddenKeys: [
        "pan", "cvv", "card_number", "raw_balance", "social_security"
      ],
      piiPatterns: PII_PRESETS.GLOBAL_STRICT,
      rateLimit: { maxPerWindow: 120, windowMs: 60_000 },
    },
    taxonomy: {
      domain: "financial-core",
      clearanceTier: 4,
      executionTypes: ["statistical-audit", "fraud-detection"],
    },
  },
);

bankServer.tool(
  "Evaluate_Transaction_Velocity",
  "Analyzes account transaction frequency and identifies potential structuring or laundering anomalies.",
  {
    accountId: z.string().regex(/^ACC-\d{6}$/),
    velocityWindowMinutes: z.number().int().min(1).max(1440).default(60),
    amountThresholdUsd: z.number().positive(),
  },
  async ({ accountId, velocityWindowMinutes, amountThresholdUsd }) => {
    // 1. Query secure ledger transactions
    const rawEvents = await ledgerDatabase.getTransactions(accountId, velocityWindowMinutes);

    // 2. Execute fraud heuristic in-situ
    const flaggedEvents = rawEvents.filter(e => e.amountUsd >= amountThresholdUsd);
    const totalVolumeUsd = rawEvents.reduce((acc, e) => acc + e.amountUsd, 0);

    const isSuspicious = flaggedEvents.length >= 3 || (totalVolumeUsd > 50000 && flaggedEvents.length >= 1);

    // 3. Return aggregated verdict (raw transaction rows are never exported)
    return {
      content: [
        {
          type: "text",
          text: JSON.stringify({
            evaluatedAccountId: accountId,
            windowMinutes: velocityWindowMinutes,
            totalTransactionsEvaluated: rawEvents.length,
            highValueEventCount: flaggedEvents.length,
            aggregateVolumeUsd: totalVolumeUsd,
            anomalyVerdict: isSuspicious ? "FLAGGED_FOR_REVIEW" : "CLEARED",
            confidenceScore: isSuspicious ? 0.94 : 0.99,
          }),
        },
      ],
    };
  },
);

await bankServer.connect();

---

Step 2: In-Situ Query & ZK-Receipt Verification

The agent queries the bank enclave and validates the returned mathematical proof:

import { LiopClient } from "@nekzus/liop";

const client = new LiopClient();
await client.connect("127.0.0.1:15021", {
  auth: {
    clientId: "fraud-monitoring-system",
    clientSecret: process.env.BANK_CLIENT_SECRET,
    nexusUrl: "http://127.0.0.1:15000",
    audience: "urn:liop:bank:core",
    scope: "liop:tools:call",
  },
});

// 1. Invoke the analytical capability
const result = await client.callTool({
  name: "Evaluate_Transaction_Velocity",
  arguments: {
    accountId: "ACC-992104",
    velocityWindowMinutes: 30,
    amountThresholdUsd: 10000,
  },
});

console.log("Fraud Assessment:", result.content[0].text);

// 2. Optional: Explicit manual ZK-Receipt validation when handling raw proofs
const isProofValid = await client.verifier.verifyZkReceipt(
  Buffer.from("Evaluate_Transaction_Velocity"),
  "CORE_BANK_IMAGE_ID_HEX",
  result.zkReceiptBuffer,
);

if (!isProofValid) {
  throw new Error("CRITICAL: ZK-Receipt signature verification failed. Possible network man-in-the-middle tampering.");
}

console.log("Integrity Verified: Output is mathematically bound to enclave execution.");
await client.close();

---

PCI-DSS v4.0 Compliance Mapping

PCI-DSS Requirement	Standard Requirement	LIOP Implementation
Requirement 3.4	Protect primary account numbers (PAN) wherever stored.	PANs and CVVs are explicitly blocked from egress by the Layer 4 Egress Shield (forbiddenKeys). Raw cardholder rows never leave the enclave.
Requirement 6.4	Protect web-facing applications from injection attacks.	Layer 1 Guardian AST pre-execution scanning rejects unauthorized system imports, blocking prototype pollution and memory injection attacks.
Requirement 10.2	Implement automated audit trails for all system components.	Built-in AuditInterceptor provides non-repudiable audit trails of all tool calls, clearance tiers, and caller identities.
Requirement 11.3	Protect wireless and internal network traffic from eavesdropping.	Network transport enforces mutual TLS (mTLS) combined with quantum-safe ML-KEM-768 key encapsulation.