AAM · Payments · Regulatory mapping

Which regulatory requirements does the chain answer?

Federal, state, civil-enforcement, and international regimes are converging on the same expectation: independent verifiability of what a payment gateway actually executed at the moment of every transaction. Each regime today depends on records the gateway operator authors and retains. The audit-permanence chain is the structural answer.

Federal-alignedCourt-admissible architectureVendor-neutralDefensive only

TL;DR

One-paragraph summary for a reviewing authority.

The Payment Card Industry Data Security Standard v4.0 — v4.0.1 the current revision — audits configuration; the Federal Trade Commission’s consumer-protection authority under 15 U.S.C. § 45 reaches breach mishandling and deceptive security claims; all 50 states, the District of Columbia, Guam, Puerto Rico, and the U.S. Virgin Islands operate breach- notification statutes; state Attorneys General hold consumer-protection authority under state UDAP statutes; EU Regulation 2016/679 Article 32 imposes integrity-and- confidentiality requirements on personal-data processing; Directive (EU) 2022/2555 (NIS2) imposes operational- resilience requirements on essential and important entities, while Regulation (EU) 2022/2554 (DORA) governs payment service providers themselves as lex specialis and ICT service providers handling payment flows remain in NIS2 scope. Each regime today depends on records the gateway operator authors, retains, and surfaces. Knox produces a parallel tamper-evident record of every gateway code path executed, every input received, every output produced, every agent attestation, and every side effect emitted — content-addressed, sequence-linked, hash-chained, and Bitcoin-anchored via OpenTimestamps. The chain is verifiable by any third party without trusting Bonis, the gateway operator, the processor, or the merchant to remain online or cooperative. Bonis operates the evidence layer only; lawful authority decides what to do with the evidence.


The mapping question

Each regime asks the same underlying question.

What did the payment gateway actually do, at what moment, under what policy, with what inputs, producing what outputs, triggering what side effects. PCI-DSS frames it as integrity of payment-processing components. The Federal Trade Commission frames it as security claims versus security reality. State breach-notification frames it as scope and timing of consumer notification. State Attorneys General frame it as consumer-protection enforcement under UDAP statutes. EU GDPR Article 32 frames it as integrity-and-confidentiality of personal-data processing. NIS2 frames it as operational resilience of essential and important entities. The questions differ in caption; the underlying evidence shape is the same.

The structural challenge is also the same across regimes. The entity whose code processed the transaction is also the sole custodian of the record about what the code did. The reviewing authority depends on the operator choosing to preserve, choosing to surface, and choosing to interpret the record. When the underlying telemetry is rewritten, redacted, or reinterpreted, the regime’s authority extends only as far as the regime’s ability to detect the rewrite.

The Knox audit-permanence chain runs alongside operator telemetry, not in place of it. A code-path execution, an input received, an output produced, an agent attestation, or a side effect emitted at the gateway surface is committed at the moment it occurs and Bitcoin-anchored within the hour. The reviewing authority cross-checks the operator’s submission against the public chain. Divergence becomes a question of fact rather than a question of trust.


Six regimes, one chain

Each regulatory regime, expressed in the language of the audit chain.

Each card frames the regime as it appears to the reviewing authority, identifies the structural dependency on operator-controlled records, and names which Knox gateway_* event types produce the independent record the regime is reaching toward.

Federal · PCI SSC

PCI-DSS v4.x

What it requires

The Payment Card Industry Data Security Standard v4.0 — v4.0.1 the current revision — is in force, with merchant compliance milestones rolling through 2025 and 2026. The direction-of-travel of the standard is toward stricter integrity verifiability of payment-processing components.

Operator-side dependency

The standard is a configuration-time framework. Audits verify the state of the environment as observed during the audit window; what happens between audit windows is reconstructed from records the operator authors and retains.

Knox events that produce the independent record

gateway_code_fingerprint, gateway_input_commitment, gateway_output_commitment, gateway_agent_attestation, gateway_side_effect_record — anchored at the moment each event occurred, recoverable for cross-check against any subsequent QSA review.

PCI SSC · v4.0.1 · in force
Federal · FTC

FTC Section 5 — 15 U.S.C. § 45

What it requires

The Federal Trade Commission holds consumer-protection authority under 15 U.S.C. § 45 over breach mishandling, deceptive security claims, and inadequate breach response.

Operator-side dependency

When such an enforcement action runs, it depends on records of what the gateway actually did versus the operator’s security representations. Without independent verification, the comparison runs through operator-controlled records.

Knox events that produce the independent record

gateway_code_fingerprint and gateway_agent_attestation pin which code and which agent was operating at any moment; gateway_input_commitment and gateway_output_commitment pin the data shape; gateway_side_effect_record pins the actual consequence. The reviewing authority verifies through the public chain.

15 U.S.C. § 45 · FTC enforcement · in force
State · Breach notification

State data-breach notification statutes

What it requires

All 50 states, the District of Columbia, Guam, Puerto Rico, and the U.S. Virgin Islands operate breach-notification statutes that obligate timely disclosure of the categories of data affected and the populations notified.

Operator-side dependency

Breach scope is determined from records the operator authors. The set of transactions, customers, and time windows affected depends on what the operator’s logs preserve.

Knox events that produce the independent record

gateway_input_commitment and gateway_output_commitment pin the inputs and outputs of every transaction within the affected window; gateway_code_fingerprint pins which code path was active at each moment. The set of transactions touched by a compromised code path is recoverable from the chain.

50 states + DC + 3 territories · in force
State · Civil enforcement

State Attorneys General — UDAP authority

What it requires

State Attorneys General hold consumer-protection authority under state Unfair and Deceptive Acts and Practices (UDAP) statutes over deceptive security claims and inadequate breach response by payment-handling operators.

Operator-side dependency

When such an investigation runs, it depends on what the operator’s gateway actually did versus what the operator’s representations said. Without independent verification, the comparison runs through operator-controlled records.

Knox events that produce the independent record

gateway_code_fingerprint, gateway_agent_attestation, gateway_input_commitment, gateway_output_commitment, and gateway_side_effect_record together produce a content-addressed record of gateway behavior. The reviewing authority can verify through the public chain without taking the operator’s word for what the gateway code was doing.

State Attorneys General · UDAP · in force
International · EU GDPR

Regulation 2016/679 — Article 32

What it requires

EU Regulation 2016/679 Article 32 imposes integrity-and-confidentiality requirements on the processing of personal data, including the ability to ensure the ongoing integrity of processing systems and services.

Operator-side dependency

Demonstrated integrity is generated by the same infrastructure the operator authors and retains. Supervisory-authority review depends on operator-surfaced records.

Knox events that produce the independent record

gateway_code_fingerprint and gateway_agent_attestation provide content-addressed commitments of which code was executing and which agent was operating at any moment; gateway_input_commitment, gateway_output_commitment, and gateway_side_effect_record provide independent commitments of the data flow — independently verifiable by the supervisory authority.

EU Reg 2016/679 Art 32 · in force
International · EU NIS2 / DORA

Directive (EU) 2022/2555 — NIS2

What it requires

The NIS2 Directive imposes operational-resilience requirements on essential and important entities. Payment service providers themselves are governed by Regulation (EU) 2022/2554 (DORA) as lex specialis; ICT service providers, digital-infrastructure operators, and managed service providers handling payment flows remain in NIS2 scope under Annexes I and II. Covered entities must maintain continuous integrity assurance and timely incident reporting.

Operator-side dependency

Operational-resilience evidence is generated by the operator’s own systems; the supervisory authority’s view of resilience is shaped by what the operator chooses to surface.

Knox events that produce the independent record

The five gateway_* anchors produce a continuously verifiable, tamper-evident record of operational behavior. NIS2 and DORA incident-reporting timelines are supportable from chain queries rather than reconstructed from operator logs after the fact.

Directive (EU) 2022/2555 · Reg (EU) 2022/2554 · in force

How a regulator verifies independently

Three steps. No Bonis dependency. No operator dependency.

The verification path that gives the audit chain its authority does not require Bonis to be online, the gateway operator to cooperate, the processor to participate, or the merchant’s vendor stack to remain in business. The path uses open standards published in their respective canonical sources.

01

Resolve the anchor

Given a SHA-256 of a gateway event — code path, input commitment, output commitment, agent attestation, or side-effect record — the verifier resolves it against the Knox sequence: the anchor identifier, the sequence number, the previous-anchor hash, and the timestamp. The resolution surface is published as an open verify endpoint. The chain of sequence links is cryptographically self-consistent.

02

Walk the Bitcoin path

The hourly Merkle root containing the anchor is published to the Bitcoin blockchain via OpenTimestamps. The verifier walks from the anchor up to the Merkle root and from the Merkle root down to the Bitcoin block header. The walk is reproducible by any party with a Bitcoin full node and the OpenTimestamps client.

03

Read the protocol spec

The Knox anchor pipeline is described under a TLA+ specification and an open-spec page. The verifier reads the specification, runs the model-checker if desired, and confirms the protocol matches the chain behavior they observed in steps 01 and 02. No proprietary primitive needs to be trusted.


Defensive only

Evidence layer, not enforcement.

Bonis does not access gateways, does not intercept transaction data, does not modify, block, or rate-limit payment traffic, and does not undertake any active disruption of any external system — including a system demonstrably compromised by an attacker agent. Knox is invitational: a merchant, gateway operator, processor, or third-party auditor who wants a tamper-evident per-transaction record instruments their own emit path. Bonis produces the audit primitive; lawful authority — courts, the Federal Trade Commission, state Attorneys General, PCI-DSS qualified security assessors, EU supervisory authorities, plaintiff counsel — decides what to do with the resulting evidence.



Regulatory regimes referenced on this page — the Payment Card Industry Data Security Standard v4.0 (v4.0.1 current revision), the Federal Trade Commission’s consumer-protection authority under 15 U.S.C. § 45, state and territorial data-breach notification statutes operated by all 50 states, the District of Columbia, Guam, Puerto Rico, and the U.S. Virgin Islands, state Attorneys General consumer-protection authority under state UDAP statutes, EU Regulation 2016/679 Article 32, Directive (EU) 2022/2555 (NIS2), and Regulation (EU) 2022/2554 (DORA) — are cited from their respective public publications and regulation texts. PCI-DSS v4.0 / v4.0.1 is cited from PCI Security Standards Council public publications. State and territorial breach-notification statutes are cited from the public inventory maintained by the National Conference of State Legislatures. Federal Rules of Evidence 902(13) and 902(14) are cited as architectural targets; admissibility in any matter remains a determination of the presiding court. No partnership, customer status, prospect status, or operational engagement with the PCI Security Standards Council, the Federal Trade Commission, any state Attorney General, the European Commission, any EU supervisory authority, any payment gateway operator, any payment processor, any PCI-DSS qualified security assessor, or any cyber insurance carrier is implied or claimed.

USPTO provisional applications, inventor of record Jonis Aaron Fields: 64/038,359 (Knox · 2026-04-13), 64/012,440 (TerraVault · 2026-03-21), 64/036,498 (TrustAI · 2026-04-11), 64/002,221 (HealthAgent · 2026-03-11), 64/013,240 (DealMatcher · 2026-03-22). Provisionals are priority-date footnotes; the operating moat is shipping code, public anchors, and open-standard alignment. Bonis Systems LLC · UEI R2BPJDC5CBA3 · CAGE 1TSP2.