The Compliance Passport
Raeez Lorgat
When a human being crosses a border, they carry a passport: a self-contained record of who they are and, in the visa pages, of where they have been and who admitted them. The border officer does not call the issuing country to ask whether the traveler may travel. The officer inspects the artifact the traveler carries.
An institution crossing a jurisdictional boundary carries no artifact that does this work. When a corporation foreign-qualifies in a new state, opens a subsidiary in a new country, or executes a cross-border transaction, it must prove its compliance status to the receiving jurisdiction — and today that means querying the originating jurisdiction’s systems in real time and trusting the response.
This is a fragile arrangement. It fails when the originating system is offline. It fails when the two jurisdictions have no data-sharing agreement. It fails when the question is about historical compliance rather than current compliance, because most systems store only the latest state. And it is unverifiable by the party that needs it: the receiving jurisdiction is trusting a response from a database it does not control, cannot audit, and has no reason to trust beyond institutional comity.
The compliance passport is the institutional analogue: a self-contained, cryptographically verifiable record of an entity’s compliance history that the entity carries as it moves across jurisdictions. Verifying one requires the issuing sovereign’s authentic public keys, the versioned archives of the rules its evaluations ran under, current revocation state, and a policy for when foreign conclusions are accepted or re-evaluated. It does not require a live query to the origin.
None of the ingredients is new. Hash-chained records date to Haber and Stornetta (1991); Merkle (1987) gives compact inclusion proofs; Certificate Transparency (Laurie, Langley and Kasper 2013) operates signed append-only logs at internet scale and confronts the same stale-view problem this design bounds with freshness windows. The W3C verifiable-credential data model (W3C 2022) standardizes signed, portable, machine-verifiable attestations, with selective disclosure available through anonymous credentials (Camenisch and Lysyanskaya 2001), BBS+ signatures (Au, Susilo and Mu 2006), and SD-JWT (Fett, Yasuda and Campbell). Institutions already carry weaker analogues: the certificate of good standing is point-in-time, single-authority, and history-free; the Legal Entity Identifier and its verifiable form, the vLEI (GLEIF 2022), attest identity and role rather than compliance state; European regulatory passporting is mutual recognition by treaty, with no portable artifact at all. Even the physical analogy is closer than it first looks: a modern ePassport chip is a signed artifact verified offline under the passive-authentication mechanism of Doc 9303 (ICAO 2021) — the officer checks the issuing state’s signature without calling the issuing state. What the compliance passport adds is the content and the discipline: a per-domain compliance state vector rather than an identity claim, the full evaluation history rather than the current state, a completeness attestation that forecloses operating on half-finished evaluations, and a terminal treatment of sanctions determinations. The contribution is this composition, stated with its assumptions, not any single mechanism.
I.
Start with what compliance means for a cross-jurisdictional entity.
Compliance is not a binary state. An institution operating across borders faces requirements in many independent domains simultaneously: corporate governance, tax filing, beneficial ownership disclosure, anti-money-laundering controls, sanctions screening, securities regulation, employment law, data privacy, environmental reporting, and more. Each domain has its own regulator, its own rules, its own evaluation criteria, and its own timeline.
At any given moment an institution might be fully compliant in corporate governance, pending evaluation in tax, exempt from securities regulation because it is not a public company, and non-compliant in beneficial ownership after a missed filing. These are four different states across four different domains, all simultaneously true. In general each domain sits, at each evaluation, in one of five states: compliant, non-compliant, pending, exempt, or not applicable. Reducing this to a single “compliant” bit destroys exactly the information the receiving jurisdiction needs.
The compliance passport stores the full structure: one state per compliance domain, recorded at every evaluation the entity has undergone — a per-domain state vector at each evaluation, and the sequence of those vectors as history.
II.
Storing the current compliance state is the easy part. The hard part is history.
Consider a concrete scenario. Corporation X was incorporated in jurisdiction A two years ago. It was evaluated for compliance fourteen times over those two years: once per quarter in tax, twice per year in beneficial ownership, and twice for sanctions screening when it executed cross-border transactions. On its sixth tax evaluation it was found non-compliant; on the seventh, after filing amended returns, compliant again.
Now Corporation X wants to foreign-qualify in jurisdiction B. Jurisdiction B asks whether the entity is compliant. On the current state alone the answer is yes. But jurisdiction B may need the history of non-compliance and remediation: a jurisdiction can apply heightened scrutiny to entities with a record of tax non-compliance, and its regulations can require disclosure of prior compliance failures as a condition of registration.
Self-reported history is worthless for this purpose. Corporation X has every incentive to omit the unflattering parts. What is needed is a compliance record Corporation X cannot edit after the fact.
III.
Each compliance evaluation produces a new version of the passport, and the evaluating authority signs each version. That authority is one per jurisdiction: the domain regulators of §I do not sign the passport; their determinations enter each evaluation as evidence, and the issuing authority records the resulting domain states and signs the version. A version records the per-domain state vector for that evaluation, the hashes of the evidence behind each determination, the version of the rule archive the evaluation ran under, the time of the evaluation, an evaluation counter, the entity’s identifier, and the SHA-256 digest of the previous version. The first version carries counter one and a fixed genesis constant in place of a predecessor digest. The signature covers all of it, the previous-version digest included. The result is a signed hash chain: a sequence of evaluations in which each entry cryptographically commits to its predecessor and every link carries the issuer’s signature.
The chain alone proves nothing against the adversary that matters here. The party carrying the passport is the entity itself, and the entity can recompute hashes as easily as any verifier; nothing stops it from rebuilding a perfectly consistent unsigned chain around an edited history. The property rests on the signatures. Stated as a proposition: assume the hash function is collision-resistant, the signature scheme is existentially unforgeable under chosen-message attack, the verifier holds the issuer’s authentic public key, and the issuer signs one linear history per entity — one first version, and at most one successor per version. If the verifier checks that every presented version carries a valid issuer signature over its full contents, that the first presented version carries counter one and the genesis constant, that each later version’s previous-version digest equals the hash of the presented predecessor, and that the counters increment by one, then the presented passport is a prefix of the history the issuer signed for that entity, ending at the presented head. The argument is short. A presented version the issuer never signed is a forgery. Two distinct presented histories under the same signed head collide the hash function somewhere along the chain. Because each signed version names the entity and its counter, signed material cannot be grafted in from another entity’s passport or reordered within this one. And a presentation that omits the earliest versions fails the genesis check at its first entry, so what truncation can still remove is the end of the history.
The proposition is aimed at the carrier, and that is the point: the threat model is an entity with every incentive to edit its own past. It does not protect against the issuer. An issuer that attests falsely, misrecords what a domain regulator determined, or signs two competing histories, defeats the record from above. The passport makes the origin’s attestations portable and unalterable; it does not make them true. That residual trust in the origin is explicit, and it is the trust a border officer already places in the state that issued a physical passport.
One attack passes every check above, and it is exactly the attack in the scenario of §II: present an old head. Corporation X presents the version signed just before the adverse tax finding — genuinely signed, chain intact, counter consistent — and withholds everything after it. The presentation is a true prefix, so the guarantee is delivered exactly as stated: the verifier sees an authentic history up to the presented head, not the latest one. The countermeasure is freshness. The receiving jurisdiction’s policy fixes a maximum age for the presented head, measured from its signed evaluation time — an entity under quarterly obligations cannot explain a head nine months stale — and where the stakes warrant it, the origin can anchor its latest head digest where verifiers can see it, the mechanism transparency logs use for the same problem (Laurie, Langley and Kasper 2013). Within the freshness window, what truncation can hide is bounded by what can happen inside the window.
Verification also has a narrower, disclosed mode. A verifier need not see the whole passport. Each version commits to its per-domain entries through a hash tree whose root the signature covers, so the entity can present a version’s signed fields with the entries withheld and disclose a single entry — one domain’s state, its evidence hashes, its rule-archive version — together with the short inclusion path from that entry to the committed root. Under the hypotheses of the proposition, plus three the receiving side enforces — the rule-archive version falls inside the window that side accepts, the signing key is unrevoked at verification time, and the presented head falls inside the maximum age that side fixes — an accepted disclosed entry is attributable to the issuer, included in the version it claims, evaluated under an accepted rule archive, and fresh enough for the receiving policy. The argument is the same forgery-or-collision argument, run along the inclusion path. What the disclosed mode does not do is prove anything about what was withheld. Establishing a predicate over hidden contents — that no domain is non-compliant, say, while revealing none of them — requires a zero-knowledge construction this paper does not build. That is the open problem. The passport makes an entity’s history legible to receiving regulators by default, and until the problem is closed, selective disclosure here means attributable partial revelation, not privacy.
The evaluation counter earns its place in the disclosed mode. In a fully disclosed chain it is redundant; it equals the chain’s length. But the counter is a signed field of the head, so a verifier shown only selected entries still learns how many evaluations exist and can hold that number against the cadence the entity’s age and obligations imply. Corporation X, two years old under the obligations of §II, should show fourteen; a head attesting three says most of the required evaluations are absent from the record — never performed, or hidden behind a stale head — and says it without a single further entry being disclosed.
These checks establish the authenticity and integrity of the record. Whether the origin’s legal conclusions are then accepted, rejected, or re-evaluated is the receiving jurisdiction’s decision, taken by its own policy on top of a record it can now verify. The cryptography settles what was attested, not what the attestation is worth to the receiving side.
IV.
The signed chain handles history. A second problem is what it means for an evaluation to be complete.
In most compliance systems the evaluation is a point-in-time check: someone runs the checks, records the results, and moves on. A point-in-time check can leave domains pending — the evaluation has not yet occurred, or it awaits external input: a document from the entity, a response from a regulator, a third-party attestation that has not arrived.
This matters because a passport with pending domains is a partially completed assessment, and letting institutions operate across borders on partially completed assessments creates an obvious exploit: delay the evaluation of the domains you expect to fail, and let pending stand in for compliant.
The passport addresses this with a completeness attestation. For the operations the receiving jurisdiction’s policy designates, the passport must carry a signed statement by the evaluating authority that no compliance domain is pending: every domain is in a determined state — compliant, non-compliant, exempt, or not applicable. The attestation is a signed, structured artifact listing every domain, its determined state, the rule-archive version applied, and the hashes of the evidence behind each determination, and it can be verified without contacting the origin. It means one specific thing: at the attested moment, this entity had no unresolved compliance question in any domain. Which operations require it is the receiving policy’s decision; the passport’s job is to make the attestation checkable.
V.
One compliance domain receives distinct structural treatment: sanctions.
The legal structure is specific. Under the United States regime, the International Emergency Economic Powers Act supplies the authority to prohibit the transactions at issue (50 U.S.C. § 1702(a)(1)); civil penalties attach without regard to knowledge or intent (§ 1705(b), enforced on a strict-liability basis), while criminal liability requires a willful violation (§ 1705(c)); the largest enforcement actions have reached billions of dollars. The prohibitions bind the persons and transactions within the sanctioning sovereign’s reach, and only those. Other sovereigns maintain their own lists, and some prohibit compliance with certain foreign sanctions inside their territory — Council Regulation (EC) No 2271/96 is the European instance. Sanctions exposure is therefore a determination each jurisdiction makes under its own law, which is why the passport carries it as a first-class, per-jurisdiction fact rather than folding it into an aggregate.
The passport encodes the asymmetry structurally. Any domain can occupy any of the five states, and mitigations — licenses, humanitarian carveouts, sovereign exemptions, recognition of another sovereign’s determinations — enter the evaluation as evidence before the sanctions verdict is fixed, never as overrides after it. Once fixed, a non-compliant sanctions determination is terminal for the operation under the receiving jurisdiction’s policy: no local override, escalation path, or executive exception converts it into permission. A different sovereign proceeds only by its own independent sanctions re-evaluation, or under an explicit certificate — one its policy accepts — by which the two sovereigns recognize a shared sanctions authority.
A passport whose sanctions domain is non-compliant is therefore blocked as a whole. The receiving verifier cannot authorize the operation on its strength, however clean every other domain reads.
VI.
So far the passport is a per-entity construct. But institutions exist in specific jurisdictions, and the compliance requirements differ by jurisdiction.
A corporation registered in the Cayman Islands faces different compliance domains than one registered in Florida. Securities regulation may not apply at all in one jurisdiction and be the dominant concern in another. Tax requirements differ in structure and rate. Governance rules vary from the number of directors required to whether a corporate secretary is mandatory.
The passport is therefore scoped to a jurisdiction. An entity operating in three jurisdictions has three passports, each evaluated against that jurisdiction’s requirements, because compliance is always compliance with a particular jurisdiction’s rules.
When an entity moves from jurisdiction A to jurisdiction B, the operative question is whether its compliance history in A meets B’s requirements for entry — a question about compatibility between two passport instances, answered under B’s rules. Some jurisdictions accept another’s assessments through mutual recognition; others require fresh evaluation. Either way, the admission itself is recorded on B’s side: B’s first evaluation of the entity opens B’s passport, and the accepted head of the A-passport enters that evaluation as evidence, its hash recorded like any other evidence the determination relied on. Here the physical analogy bends. A traveler’s passport collects foreign stamps in one home-issued booklet; the compliance passport keeps each jurisdiction’s record under that jurisdiction’s own signature, and hash references tie the records together.
VII.
The compliance passport is a solution to a trust problem. When institutions move across jurisdictional boundaries, someone has to vouch for their compliance history. The question is who, and on what basis.
Option one: real-time queries. The receiving jurisdiction calls the originating jurisdiction’s system and asks for current status. This requires connectivity, API compatibility, and data-sharing agreements; it returns current state only, not history; and it fails closed whenever the originating system is unavailable.
Option two: self-report. The entity describes its own history. This trusts exactly the party with the greatest incentive to misrepresent.
Option three: the passport. A signed, hash-chained, self-contained record the entity carries. The history is tamper-evident because every version is issuer-signed and each signature covers the previous version’s digest; the completeness attestations are verifiable without contacting the origin. The receiving jurisdiction needs neither the entity’s honesty nor the origin’s uptime. What it still needs, it needs explicitly: collision-resistant hashing, unforgeable signatures, authentic sovereign keys and their revocation state, accepted rule archives, a freshness bound on the presented head, and a policy for which foreign conclusions count. The trust is minimized, not eliminated, and the residue is named: the origin’s honesty as an evaluator, the provenance of its keys, and the discipline of the freshness window — the residue the physical passport has always carried.
The hard problem was never running a compliance check; any system can run one. The hard problem is making the result portable, verifiable, and historically grounded, so that when an entity crosses a boundary the receiving side holds something better than a promise and cheaper than a live query into a database it does not control.
References
Au, M. H., Susilo, W. and Mu, Y. (2006). “Constant-Size Dynamic k-TAA.” Security and Cryptography for Networks (SCN 2006), LNCS 4116, Springer.
Camenisch, J. and Lysyanskaya, A. (2001). “An Efficient System for Non-transferable Anonymous Credentials with Optional Anonymity Revocation.” Advances in Cryptology — EUROCRYPT 2001, LNCS 2045, Springer.
Council of the European Union (1996). Council Regulation (EC) No 2271/96 protecting against the effects of the extra-territorial application of legislation adopted by a third country. Official Journal L 309.
Fett, D., Yasuda, K. and Campbell, B. Selective Disclosure for JWTs (SD-JWT). IETF Internet-Draft draft-ietf-oauth-selective-disclosure-jwt (work in progress).
GLEIF (2022). verifiable LEI (vLEI) Ecosystem Governance Framework. Global Legal Entity Identifier Foundation.
Haber, S. and Stornetta, W. S. (1991). “How to Time-Stamp a Digital Document.” Journal of Cryptology, 3(2), 99–111.
ICAO (2021). Doc 9303: Machine Readable Travel Documents. Eighth edition; Part 11: Security Mechanisms for MRTDs. International Civil Aviation Organization.
Laurie, B., Langley, A. and Kasper, E. (2013). Certificate Transparency. RFC 6962.
Merkle, R. C. (1987). “A Digital Signature Based on a Conventional Encryption Function.” Advances in Cryptology — CRYPTO ’87, LNCS 293, Springer.
United States Congress (1977). International Emergency Economic Powers Act. 50 U.S.C. §§ 1701–1708.
W3C (2022). Verifiable Credentials Data Model v1.1. W3C Recommendation.