Privacy in MATTR's architecture

Privacy is a foundational property of the MATTR product stack, not an afterthought layered on top. The decentralized credential model that MATTR is built on shifts data control away from central intermediaries and toward the holder. MATTR's job is to provide the infrastructure that makes this shift practical at scale, while ensuring that the infrastructure itself does not become a new point of correlation or data accumulation.

This page describes the principles that shape how MATTR thinks about privacy across the credential lifecycle. For details on specific product areas, see the dedicated privacy pages for issuance, holding, verification, and digital trust services.

Privacy by design

Privacy by design means that privacy properties are built into the architecture of a system rather than enforced through policy alone. In a federated identity model, the identity provider sees every transaction. Privacy then depends on the provider's contractual obligations and audit posture. In a decentralized credential model, the issuer is out of the transaction loop by design. The architecture itself prevents the identity provider from observing how a credential is used.

MATTR products implement this principle across the credential lifecycle:

• During issuance, MATTR VII acts as a transit platform. Claims flow through the platform to produce a signed credential, and the credential is delivered to the holder's wallet. Claim data is not retained beyond what is necessary to complete issuance. Limited information can optionally be retained to support credential lifecycle management.
• During holding, credentials live on the holder's device. MATTR Pi Holder SDKs and MATTR GO use platform secure storage (Secure Enclave on iOS, Keystore on Android) to protect credentials and keys at rest.
• During verification, the verifier checks cryptographic proofs locally. There is no requirement to contact the issuer at presentation time, and no central party is informed that a verification has taken place.
• In digital trust services, MATTR publishes trust information so that participants can evaluate trust independently. The trust service does not sit in the transaction path and does not see individual verifications.

The technical instruments that make this possible are described in What is a decentralized trust model? and Selective disclosure.

Data minimization

Data minimization is the principle that systems should collect, transmit, and retain only the data strictly required for a defined purpose. Verifiable credentials make this practical in ways that earlier identity models could not:

• Selective disclosure lets a holder reveal only the specific attributes a verifier needs (for example, "over 18: yes") rather than the full contents of the credential. See Selective disclosure for more.
• Offline verification removes the need for verifiers to contact the issuer at presentation time. The issuer cannot observe verification activity.
• Transit-only processing is the default for MATTR VII. The platform does not persist claims in issued credentials by default. Where persistence is needed for a specific business reason, it is a deliberate, configurable choice made by the customer.

For developers building on MATTR, the practical implication is that data minimization is the path of least resistance. Following the default patterns produces a minimal data footprint without additional engineering work.

Privacy backed by the MATTR Security Framework

Architectural privacy properties are necessary but not sufficient. They have to be reinforced by the organizational controls that govern how MATTR builds, operates, and supports its products.

MATTR operates a Privacy Information Management System (PIMS) as part of the broader MATTR Security Framework (MSF). The framework covers policies, procedures, roles, training, and tooling across cyber security, data and privacy protection, prevention, enterprise risk, and incident response. Independent assessments include:

• ISO/IEC 27001:2022 certification, maintained on an annual assessment cycle.
• SOC 2 Type 2 audit, performed annually by an independent auditor.
• Annual external code audit of the MATTR codebase by Trail of Bits.
• Self-assessments against ISO 27701, OWASP Top 10 Privacy Risks and ISO 29100.

The MATTR platform is designed to support customers meeting their own obligations under GDPR, UK GDPR, the New Zealand Privacy Act 2020, the Australian Privacy Principles, California CCPA/CPRA, Quebec Law 25, and Switzerland's revised FADP, among other regimes.

For full detail on policies, procedures, roles, retention schedules, sub-processors, and data residency, see the published Privacy Policy and the Data Processing Terms. MATTR's Data Management & Protection Plan is available to customers on request via privacy@mattr.global.

How privacy responsibilities are shared

In a typical deployment, MATTR provides the credential infrastructure and the customer configures it for a specific use case. This produces a shared responsibility model:

The architecture removes specific privacy risks (issuer-side surveillance, central correlation across verifications) but it does not absolve customers of the responsibility to design their issuance and verification flows in line with applicable privacy law.

Frequently asked questions

Where is customer data stored?

By default, MATTR does not store the personal data inside verifiable credentials. The MATTR VII platform is transactional: claims pass through it during issuance to produce a signed credential, and the credential is delivered to the holder's wallet. The platform retains a small amount of metadata for audit and lifecycle operations (such as a hash of the issued credential and a reference to the user it was issued to), but not the underlying claim values, unless the customer has explicitly configured them to be persisted.

MATTR operates regional cloud deployments in the United States, Canada, Europe, Singapore, Australia, and New Zealand. These regions are primarily where customer data is processed in transit during issuance and verification, not where the personal data inside credentials is stored long term. Where data is processed, it stays within the boundary of the chosen AWS region except for specific, listed sub-processors that may operate in adjacent regions. The current list of sub-processors is published at /docs/resources/terms/data-sub-processors.

Is customer data encrypted?

Yes. Sensitive data is encrypted at rest using AES-GCM and in transit using TLS. All APIs exposed by the MATTR platform require HTTPS. Access to encryption keys is treated as privileged access, with MFA, monitoring, and alerting.

Are credentials issued by MATTR VII privacy preserving?

The MATTR VII platform implements credential formats (mDocs, CWT, Semantic CWT) designed for privacy-preserving use. mDocs support selective disclosure and offline verification, letting holders share only the attributes a verifier asks for. Whether a specific deployment is privacy preserving in practice depends on how the customer configures issuance, what claims they include, and how verifiers consume the credential. The architectural building blocks support a minimal-data design, and customer configuration determines the outcome.

Does MATTR track how credentials are used after issuance?

No. Once a credential is issued to a holder's wallet, MATTR has no visibility into where, when, or how it is later presented. The decentralized architecture makes this technically impossible from the issuer side; the platform does not record or have access to verification events at third-party verifiers.

Can MATTR access the data inside a verifiable credential?

Only in narrow circumstances. Claims pass through the platform during issuance to be signed into a credential, and the resulting credential is delivered to the holder. Claims are not persisted by default. Limited information may be retained for audit purposes (for example, a hash of the issued credential), but this does not include the underlying claim values unless the customer has explicitly configured them to be persisted.

How does MATTR handle data breaches?

A data breach is classified as a security incident under the MATTR Security Framework and is managed through the documented Incident Management Procedure as a Severity 1 or Severity 2 incident. Customers are notified in line with their contractual terms and applicable regulatory requirements. The Data Breach Procedure is part of the MSF and is reviewed on an ongoing basis.

Where can I see the full list of sub-processors?

The published list is at /docs/resources/terms/data-sub-processors. It includes the sub-processor's purpose, the data category processed, and the data location.