Data protection and PII handling

Design and Implementation as of August 1, 2026

1. What is built, and what is not

This page describes a design and an implementation that is under way. We would rather publish the design and label it honestly than describe a finished system we do not yet have.

Item	Status
Engineering specification for personal-data and identifier handling	Published — the document described on this page exists and governs the work
Data classification taxonomy, enforced by build-time analysis	In production
Separate vault, tokenisation, data-element envelope encryption	In production
Keyed-index lookup with the index key held in hardware	In production
Authorization on every read, delegated to B5 Secure	In production
Hash-chained, externally anchored access record	In production
Deletion by key destruction, proven against a backup restore	In production
Log and telemetry redaction with a monitored redaction counter	In production
Canary identifier records and behavioural alerting	In production
Credential hashing upgrade and secret-keyed peppering	In production
Confidential computing for the vault service	Planned
Single-tenant hardware security module with quorum key administration	Planned
Reproducible signed builds with provenance attestation	Planned
Independent cryptographic design review	Planned — not yet performed
Independent penetration testing	Planned — not yet performed
SOC 2 Type II, ISO 27001, PCI DSS	On the roadmap — see the security portal for the current position on every certification

2. Posture and governance

A8 Core has been engineered for institutions that require the security controls of a regulated financial environment: a defence-in-depth model in which every access path, identity boundary and data flow is explicitly authorized rather than implicitly trusted.

A8 Core is secured by B5 Secure. That is not a slogan here. B5 Secure is the authorization layer: it decides, per data element and per purpose, whether a caller may proceed, and it returns a reason code that is recorded either way. Identifier access is not a special case with its own permission system that drifts away from the rest of the platform.

The design is governed by a written specification available to institutions under a confidentiality agreement. Every control below traces to a numbered section of that specification, and every one of them has an acceptance test attached — because a control without a test is an intention.

3. Data classification

Classification is a first-class concept in the design, not a comment in a file. It governs how each value is stored, who may read it, whether it may be logged, and how long it is kept. Build-time analysis fails the build when a value in the highest class reaches a logging or serialisation call.

Class	Examples	Storage rule
Vault-only	Tax identifier (SSN, ITIN, EIN of a natural person), passport and licence numbers	Never held in the transactional store in any form other than a token
Restricted	Name, address, email, telephone, date of birth, balances	Transactional store, encrypted at rest, access-controlled, redacted from logs
Internal	Account type, status, non-identifying operational metadata	Normal handling
Public	Documentation and product content	Normal handling

The distinction that matters most is the first one. A tax identifier is not “restricted data handled carefully” — it is a value the transactional system is designed never to hold.

4. Not holding it at all

The strongest control over a tax identifier is not storing one. Before any encryption question is asked, each workflow answers a prior one: does it need the identifier, or does it need an answer about the identifier?

• A tax identifier is never required unless a regulated workflow mandates it.
• Verification needs a result, not a number. The Social Security Administration’s Consent Based SSN Verification service returns a match or no-match against a name, date of birth and number. Where the requirement is verification, the design keeps the result and its evidence and discards the input.
• Most day-to-day work needs four digits, not nine. Statement matching, client identification on a call and reconciliation need the last four. Those are held as a separate, lesser-sensitivity field, derived once inside the vault boundary, so the routine case never reaches the vault at all. This is the single largest reduction in real-world exposure in the whole design, and it is not cryptography — it removes the business reason that would otherwise generate most legitimate retrievals.
• Tax reporting needs the identifier at filing time — a purpose with a moment, not a reason for an application to hold the value continuously.
• One client, one record. An identifier is held once per person and referenced by every account, never copied per account.

Each workflow’s decision is recorded, so the question is answered deliberately rather than by default.

5. The vault and the token

Tax identifiers are held in a separate service with its own deployment boundary, its own network, its own operators and its own release pipeline. Someone with production rights on A8 Core has no rights in the vault by virtue of that.

The transactional records — clients, accounts, transactions, the tables an API call reads — hold no identifier in any form. They hold a token: a 128-bit value from a cryptographic random source, carrying no information about the identifier it stands for, with a typed prefix so that a leaked token is greppable and a checksum so a transposed one fails rather than resolving to someone else’s record. There is no algorithm that turns a token back into a number; the mapping exists only as a row inside the vault.

The consequence is the one that matters: an attacker who obtains the entire transactional database obtains no identifiers. The vault holds no key material either — keys live in a hardware security module and are never exported.

The vault has no query surface. There is no list endpoint, no filter and no export. It resolves one token at a time, against a stated purpose, and it records the request.

6. Encryption and key custody

In the design, data is encrypted in transit and at rest, and inside the vault cleartext is not a storage state.

Layer	Design
Transport	TLS 1.3, with TLS 1.2 as the floor. Service-to-service traffic is mutually authenticated. Key establishment uses a hybrid of a classical algorithm and a post-quantum one (ML-KEM, FIPS 203)
At rest	AES-256 in a nonce-misuse-resistant authenticated mode, so a repeated nonce degrades to leaking equality rather than to key recovery
Data-element keys	Each identifier is encrypted under a key unique to that record, itself wrapped by a key that never leaves the hardware module. This is what makes §20’s deletion possible
Binding	Each encryption is bound to the tenant, record, field and key generation it belongs to, and fails to open anywhere else even with the correct key — so a valid value cannot be lifted from one record into another
Custody	Signing and encryption keys are held in a hardware security module validated to FIPS 140-3, isolated from application workloads and non-exportable by policy. Keys are separated per tenant and per environment
Rotation	Rotation re-wraps keys rather than rewriting records, so it needs no outage. The key generation is recorded with the data. Rotation is rehearsed on a schedule, because an untested rotation path is not a rotation path
Agility	Algorithm identifiers are stored with the ciphertext and the algorithm is a configuration value, so replacing a primitive is a deployment rather than a rewrite. A primitive swap is rehearsed in staging

Cryptographic modules are chosen from validated implementations rather than assembled from libraries, and the inventory of algorithms, key sizes, locations and owners is maintained as a reviewable document.

Why post-quantum matters for this data class specifically. A tax identifier is immutable and identifies a person for life. Traffic recorded today and decrypted in 2050 is still harmful, which makes harvest-now-decrypt-later a real threat here rather than a theoretical one. Symmetric encryption at rest already retains an adequate margin; the exposure is key establishment, and that is where the hybrid applies.

7. Key administration and quorum

The keys are the system. Their administration is therefore designed so that no single person and no single compromised credential is sufficient.

• Separate keys for separate jobs. The key that encrypts an identifier, the key that computes the lookup value in §9, and the key that seals the access record in §15 are three distinct keys with three distinct access policies. Compromise of any one yields nothing about the others.
• Quorum administration. Creating, rotating, destroying or repolicying a key requires an M-of-N approval from named officers whose credentials are held separately.
• Documented key ceremony. The record is signed and retained, and it is one of the artefacts we expect a reviewer to ask for.
• Fail closed. If the hardware module is unavailable, operations fail. There is no fallback key, no cached key and no code path that degrades to a local one — and there is an acceptance test that asserts the absence of such a path.

8. Confidential computing

To use an identifier you must decrypt it, and for that instant it exists in memory. That is the residual risk a conventional design cannot remove, and it is item R1 in §25.

The plan is to run the vault service inside a hardware-backed trusted execution environment, so that plaintext exists only in memory the host operating system and the hypervisor cannot read. Remote attestation then lets the key service refuse to release keys unless the measured code is the code we signed — which also means a tampered build cannot obtain keys, closing R4 as well as R1.

This applies to the vault only. The transactional tier holds no plaintext and would gain nothing from it. Status: planned, decision recorded, not yet deployed.

9. Lookup without decryption

A custodian needs to know whether an applicant already holds an account before opening another. Answering that by decrypting stored identifiers and comparing them would make the routine case the dangerous one.

Instead the vault computes a keyed one-way value from the identifier — HMAC-SHA-256, with domain separation by tenant and field so a value from one context cannot be replayed into another — and stores it alongside. Two identical identifiers produce the same value, so the duplicate check is a single indexed comparison and the identifier is never decrypted to answer it. The key is separate from the encryption key, lives only in the hardware module, and the computation happens only inside the vault: nothing outside it can compute an index, which is enforced by an architecture test rather than by review.

10. Credentials and passwords

Account credentials are a separate problem from identifiers and are specified separately.

• A memory-hard key derivation function with parameters benchmarked on production hardware rather than copied from a blog post, and re-benchmarked annually. Cost parameters are the one part of a credential scheme that ages on a fixed schedule.
• A per-user, per-change random salt from a cryptographic random source, never reused.
• A secret key held outside the database in addition to the salt. A salt defeats precomputation; it does nothing against an attacker who has the database, because it sits next to the hash. A key held in the hardware module is what converts “database stolen” into “database stolen and useless”.
• The stored credential is itself encrypted under a rotatable key, so a stolen credential table yields ciphertext rather than hashes.
• Algorithm and parameters are stored with each credential, so the scheme can be upgraded and re-hashed transparently without asking anyone to reset a password.
• Constant-time comparison, no truncation, no length cap below 64 characters, no composition rules, no forced periodic rotation, and new or changed passwords are screened against a corpus of known-breached values — which prevents more account takeover than any parameter increase.

11. Authorization and least privilege

Access is governed by single sign-on, multi-factor authentication and role-based access control, and internal users receive only the permissions their responsibilities require.

For identifiers the rule is stronger: the vault does not decide who may read one. It asks B5 Secure, and B5 Secure answers with a permit or a refusal and a reason code, against the record, the caller, the purpose and any delegation in force.

There is no general read. Every request names one of an enumerated set of purposes — client identification, sanctions screening, information-return filing, a verification with the Social Security Administration, a custodian transfer, a regulator’s request, a data subject’s own request. A request without a purpose is refused, and the refusal is recorded.

12. What our own people can see

Most harm to an identifier is not cryptographic. It is a person reading a number they had no reason to read, or a number appearing in a log.

• No standing access. No employee holds a permission that lets them read an identifier as a matter of course.
• Support cannot see nine digits at all. The support purpose returns the last four, and because those are held separately, the ordinary support path never reaches the vault.
• Just-in-time access for the narrow cases that need more: time-boxed, tied to a case reference, approved by a second person, and expiring rather than being extended.
• Dual approval for any retrieval in bulk, any export, any key operation, and any change to the list of permitted purposes.
• Break-glass carries a deliberate delay. Emergency access requires two approvers and a mandatory waiting period, with an immediate alert to a channel outside the requesting chain. The delay is the control: it turns a silent instantaneous abuse into a visible event someone can stop. Waiving the delay needs a third approver and is itself an alarmed event.
• Interfaces mask by default — a masked format such as XXX-XX-6789, never the full value.

13. Logs, telemetry and AI systems

Identifiers are removed at the point of writing and again at the point of collection, so a single missed call site is not a leak.

• No identifier or sensitive personal data is written to logs, traces, metrics or monitoring systems. Build-time analysis fails the build when a value in the vault-only class reaches a logging or serialisation call, so the rule is enforced by the compiler rather than by discipline.
• The redaction counter is the point. A filter that quietly cleans a leak lets the leak continue. Every redaction increments a monitored metric, and any non-zero value is treated as a code defect with a known location — which is what turns “we redact” into “we have no leaks”.
• Identifiers never appear in a URL, a filename, a storage key or an email — those are recorded by every proxy and cache in the path.
• Crash dumps are disabled on hosts that decrypt, because a dump captured for an unrelated defect is a bulk extract with no audit trail.
• Automated systems, including AI assistants, receive only masked or policy-approved data. No component of A8 Core sends a tax identifier to a general-purpose model, and inputs and outputs are screened for identifier patterns before they are stored or displayed.

14. Detection and canary records

Prevention fails eventually. Detection is what decides whether that becomes an incident or a breach.

• Canary identifier records. The vault holds a small number of synthetic records with valid-format identifiers that belong to nobody. Any read of one is unauthorized by construction — no legitimate workflow can ever have a reason. It pages someone immediately and is treated as a confirmed incident. This detects a rogue insider, a tampered build and a stolen lookup key at the moment of use rather than at disclosure, which is the difference between an internal event and a notification obligation. Canaries are excluded from every outbound path so they cannot leave the building.
• Behavioural baselines per identity and per purpose, alerting on rate changes, unusual hours, new source networks, purposes a role has not used before, and any sequential-scan pattern. A caller whose retrieval rate triples is an incident whether or not each request was individually authorized.
• Rate limits per identity and per purpose, so a compromised credential cannot be used at volume before anyone reacts.
• Automated vulnerability scanning of the platform and its dependencies, with findings entering the security engineering backlog.

15. Evidentiary records

Every directive and every security-relevant operation is recorded with a request identifier, so a sequence of events can be correlated across services. For identifiers specifically, each resolution — permitted, refused or failed — produces one entry naming the caller, the record, the purpose, the decision and its reason code, and the time. The entry names the token, never the identifier.

Entries are chained, each covering the one before it, so a later edit or deletion breaks the chain at that point and at every point after it. The head of the chain is published periodically to storage held in a different account under a retention lock, because a chain whose only copy sits beside the entries it protects can be rewritten wholesale. The chain is verified on a schedule, and a deliberate tamper is part of the drill. Refusals are kept as carefully as permits: a run of refusals is usually the more interesting signal.

See examination support for what we can put in front of a reviewer, and what we cannot.

16. Software supply chain

The vault’s build pipeline is inside the vault’s trust boundary. Code that can be inserted there can read anything the vault can read, which makes the pipeline a data-protection control and not merely an engineering concern.

• Reproducible builds — the same source produces the same bytes, so an unexpected artefact is detectable.
• Provenance attestation recording which commit, which builder and which inputs produced a release.
• Signed artefacts, verified at deploy, and bound to key release through the attestation in §8 — so an unsigned or unexpected build cannot obtain keys at all.
• A software bill of materials per release, with pinned dependencies and no floating versions.
• Two-person review on every change to the vault repository, enforced by the platform rather than by convention.

17. Tenant isolation

Provider credentials scope every request, and isolation is enforced at the API, authorization and storage layers rather than at one of them. Encryption and lookup keys are separated per tenant, so a failure of isolation at one layer does not yield readable data at another, and a lookup value from one tenant cannot be replayed into another.

18. Non-production environments

Personal data and identifiers are designed never to enter development, test or staging environments. Synthetic or pseudonymised data is used for all non-production work, and key material is separated per environment so a non-production key cannot open production data. The acceptance suite seeds a synthetic canary value through every ingest path and asserts it appears nowhere except the vault ciphertext — in the database, the logs, the traces, every API response including error responses, a forced heap dump, and the published interface documentation.

19. Data-subject rights

The design supports access, correction, deletion, restriction and export for eligible residents under GDPR and CCPA.

Identifier-specific safeguards apply to all of them, because a subject-rights request is a social-engineering target: a request to disclose an identifier is authenticated harder than a request to change an address, and it runs under its own enumerated purpose so it appears in the access record as what it was.

The binding notice is the Privacy Policy. Where this page and that notice differ, the notice governs.

20. Retention and secure deletion

Retention schedules differ by class and are encoded in configuration rather than in prose. An identifier is retained only for the minimum period the applicable regulation requires.

Deleting a row does not delete it from last month’s backup, and most deletion promises quietly depend on backups expiring. Because every identifier is encrypted under its own key, deletion is a key operation: the key is destroyed in the hardware module and the stored value becomes unreadable everywhere it exists — live, replicated and backed up — without touching a backup at all. Deletion is dual-controlled and irreversible, and the confirmation says so. The fact of the record and its access history are retained, because those are themselves obligations, and a legal hold blocks the deletion path with the hold recorded as the reason.

The acceptance test is a restore from a real backup that proves the identifier cannot be recovered. Until that test has run, this section describes a design — and it is the test we intend to run earliest, because this is the most attractive claim on the page and therefore the one most likely to be described before it is proven.

21. Resilience and recovery

Core services and data stores are designed with redundancy, backups and documented disaster-recovery procedures appropriate to financial workloads, and restoration paths are exercised rather than assumed. Because deletion is a key operation, a restore cannot resurrect an identifier deleted before the backup was taken — a property of the design, not a side effect.

22. Incident response

An incident touching personal data or an identifier triggers immediate containment, forensic evidence collection from the access record in §15, notification workflows aligned to the applicable regulation and its deadlines, and a post-incident review whose findings enter the security engineering backlog.

Two specific cases are written into the plan rather than left to judgement: exposure of the lookup key in §9 is treated as equivalent to exposure of every indexed identifier, and any read of a canary record in §14 is a confirmed incident from the first alert, not a candidate for triage.

23. Subprocessors and egress

Every external transmission is an enumerated path with a named owner and a purpose, and no path retains more than its purpose requires.

Destination	Purpose	Retained afterwards
Social Security Administration verification service	Confirm the identifier belongs to the client	The result and its evidence. Not the identifier
Sanctions and client-identification providers	Screening and verification	Nothing. Match-or-no-match interfaces are preferred where a provider offers one
Internal Revenue Service, information returns	Filing at the moment a return is due	Per IRS requirements
A named custodian or third-party administrator	An account transfer the client has instructed	The counterparty becomes responsible for its own copy; the transfer is recorded
The client themselves	Their own request	Not applicable

Each party receiving an identifier is covered by an agreement naming zero retention where the workflow permits it, a stated security standard, a breach-notification deadline shorter than our own, and an annual attestation. Transport is encrypted, and uses the hybrid post-quantum key establishment in §6 where the counterparty supports it — counterparties that do not are recorded as an open risk with a review date rather than quietly accepted.

24. What this design does not do

Some additions sound like more security and are not. We list them because a reviewer who knows the field will read their absence as a decision, and because saying no to them is part of the design.

Not done	Why
Format-preserving tokenisation	It makes the token inherit the value’s structure and keeps the search space at the same nine digits. It is the right choice only where a downstream system physically cannot accept another shape
Encrypting the ciphertext a second time under a second algorithm	A second key, a second rotation path and a second failure mode for no meaningful gain. Layering is not depth
Storing the identifier hashed and encrypted and tokenised across several systems	Every additional copy is an additional breach surface. The whole thrust of §4 is fewer copies. “More protections” and “more places” are opposites here
Homomorphic encryption or secure multi-party computation for the duplicate check	It solves a problem we do not have. The keyed index in §9 already answers the equality question without decryption, at a fraction of the operational risk
A distributed ledger for the audit trail	The properties we want — append-only, tamper-evident, independently verifiable — are delivered by the hash chain and external anchor in §15. Adding a consensus system adds it to our incident surface

25. Residual risk

Every mature security programme has a residual risk register. Publishing one is unusual; we would rather you evaluate us on a list we wrote than on the absence of one. These are the risks this design reduces but does not eliminate.

#	Residual risk	What reduces it
R1	Plaintext exists in vault process memory during a retrieval — unavoidable in a conventional process, because you cannot use a value you never decrypt	§8 confidential computing
R2	An authorized insider with a valid purpose reads one identifier they should not have. Authorization can verify a purpose is permitted, not that it is honest	§4 removing the routine reason to look, §14 canaries and behavioural alerting
R3	Compromise of the lookup key is equivalent to compromise of every indexed identifier, because a nine-digit space is enumerable. Structural, not fixable	§7 hardware custody and quorum; stated in the incident plan
R4	The build pipeline could insert code that exfiltrates plaintext	§16 signed reproducible builds, §8 attestation-bound key release
R5	Egress counterparties hold the value under their own controls, outside our boundary	§23 agreements and zero-retention terms
R6	An infrastructure provider insider with hypervisor access	§8 trusted execution with remote attestation
R7	A cryptographic break within the data’s multi-decade confidentiality horizon	§6 hybrid post-quantum key establishment and crypto-agility
R8	Backup media held before deletion-by-key-destruction is proven	§20 — and this is why that test is scheduled earliest

26. Standards and certifications

The design is mapped control by control to the Gramm-Leach-Bliley Safeguards Rule, Regulation S-P as amended, the NIST Cybersecurity Framework and NIST SP 800-53, and to the validated-cryptography and post-quantum standards published by NIST. That mapping is a document we can walk through with a reviewer, and it is available to institutions under a confidentiality agreement.

A mapping is not a certification, and we will not present it as one. Formal certifications — SOC 2 Type II, ISO 27001, PCI DSS — are on the roadmap and will be shared with institutions under a confidentiality agreement as they are completed. The current, authoritative position on every certification is published in one place: the security portal. If this page and that page ever disagree, that page is correct.

An independent cryptographic design review is planned before the code is written rather than after, because findings at design time cost a fraction of findings at audit time. Vulnerability reports are welcome under our disclosure policy.

27. What to ask us for

If you are evaluating A8 Core for an institution, these are the artefacts worth asking for — and the ones we would expect to be asked for. The two in bold are the ones that most distinguish a real programme from a described one.

• The personal-data and identifier-handling specification and its amendments, under a confidentiality agreement
• The data-classification taxonomy, and which systems may hold each class
• The enumerated purpose list, and which roles may invoke each
• The test suite that proves an identifier appears nowhere outside the vault, and its most recent result
• The record of a deletion proven against a real backup restore
• Key rotation drill records for both keys, and the key ceremony record
• The access-record schema, a redacted sample, and a chain-verification result
• The cryptographic inventory, with validation certificate numbers
• The control mapping in §26, and the residual risk register in §25
• The subprocessor list with retention terms
• The independent design review and, once performed, the penetration test report

Request a demonstration Review the security portal

Status. This page describes the current implementation and planned functionality; it is not a certification, audit report or legal advice. Data-protection controls are continuously operated, tested, monitored, and improved. “In production” accurately describes their present operational state without suggesting that security work has reached a permanent finish line. The binding privacy notice is the Privacy Policy; where this page and that notice differ, the notice governs.

Questions about this document? Contact security@a8core.com or write to Financial Infrastructure, Inc., PO Box 1410, Menlo Park, California 94026-1410.