Category: Tokenization
Token Requestor ID
Also known as: TRID, Token Requester ID
Simply put
A Token Requestor ID is a unique code given to a business or entity that is authorized to ask a token provider for payment tokens. It identifies who is making the request, which helps keep the tokenization process organized and secure. Merchants and other entities typically need one before they can request network tokens.
Formal definition
A Token Requestor ID (TRID) is a unique identifier assigned to an entity, such as a merchant, that is authorized to request payment tokens (including network tokens) from a token service provider. According to EMVCo's Token Service Provider registration process, the TRID incorporates the TSP Code and uniquely identifies the pairing of a Token Requester with a specific Token Service Provider. Obtaining a TRID is commonly a prerequisite for enabling network tokenization with a given token provider. The TRID governs the identity and authorization of the requesting party and does not itself constitute the token, encrypt cardholder data, or determine PCI DSS scope; scope effects depend on the underlying tokenization implementation and its validation.
Why it matters
The Token Requestor ID establishes accountable identity within the network tokenization ecosystem. Because a TRID uniquely identifies the pairing of a Token Requester with a specific Token Service Provider, it allows the token provider and card networks to attribute token requests to a known, authorized party. This traceability is foundational to keeping the tokenization process organized and auditable, since it makes clear which entity requested which tokens from which provider.
Who it's relevant to
Merchants
Merchants that want to enable network tokenization typically need a TRID before they can request network tokens from a token provider. Because the TRID is commonly a prerequisite for this enablement, merchant onboarding and payment engineering teams should confirm the TRID requirements and assignment process with their chosen token service provider.
Payment Processors and Token Service Providers
Processors and token service providers assign and manage TRIDs as part of registering and identifying the entities authorized to request tokens. Under EMVCo's Token Service Provider registration process, the TRID incorporates the TSP Code and identifies the Token Requester-to-provider pairing, which supports orderly attribution of token requests.
Compliance and Security Teams
Compliance officers and security engineers should understand that a TRID identifies and authorizes the requesting party but does not by itself constitute a token, encrypt cardholder data, or determine PCI DSS scope. Any scope effect depends on the underlying tokenization implementation and its validation, so these teams should assess the full solution rather than relying on the presence of a TRID.
Payment Engineering and Integration Teams
Developers integrating with token providers work directly with TRIDs when configuring network token requests. They should treat obtaining and correctly referencing the TRID as part of enabling network tokenization, and confirm provider-specific requirements against current documentation from the relevant token service provider.
Inside TRID
Token Requestor
The entity that submits a request to a token service provider to have a payment token generated for a specific use case, such as a mobile wallet, card-on-file merchant, or device manufacturer. The Token Requestor ID identifies this entity within the tokenization ecosystem.
Identifier assigned by the token service provider
The Token Requestor ID is an identifier issued to a registered token requestor by the token service provider (often operated by or on behalf of a card network) so that token operations can be attributed to the requesting entity.
Association with a token domain or use case
The ID helps bind tokens to a defined context, such as a particular channel, device, or domain of use, which can constrain how and where a token may be used. The precise controls depend on the tokenization implementation and the governing network rules.
Relationship to network tokenization, not encryption
A Token Requestor ID is a construct of a tokenization scheme, where a surrogate value (token) replaces a PAN. This differs from encryption, truncation, masking, and hashing, which transform or reduce data by other means; the effect on PCI DSS scope depends on implementation and validation rather than the presence of an ID.
Common questions
Answers to the questions practitioners most commonly ask about TRID.
Is a Token Requestor ID the same thing as the payment token itself?
No. A Token Requestor ID identifies the entity that requested tokenization from a token service provider; it is not the token that replaces a PAN in a transaction. The token is the surrogate value used in place of the underlying account number, while the Token Requestor ID is an identifier assigned to the requesting party so the token service provider can attribute and manage token requests. Treating the two as interchangeable can lead to confusion about what data is being transmitted and what must be protected.
Does having a Token Requestor ID mean my tokenization implementation is automatically PCI DSS compliant or out of scope?
No. A Token Requestor ID is an identifier used within a token service provider's ecosystem and does not by itself establish PCI DSS scope or compliance. Whether tokenization reduces or removes systems from scope depends on the specific implementation, how tokens are generated and validated, and how the assessment is documented and confirmed, not on the presence of an identifier. You should confirm scope impact through your own validation rather than assuming it from the label.
How do I obtain a Token Requestor ID for our organization?
A Token Requestor ID is assigned by a token service provider as part of an onboarding or registration process for entities that will request tokens. The specific steps, eligibility, and documentation requirements are defined by the token service provider and the applicable network or program rules, which vary by provider and region. Confirm the current onboarding requirements directly with the token service provider you intend to work with rather than assuming a standardized process.
Where does the Token Requestor ID appear in the transaction and token lifecycle?
The Token Requestor ID is used to attribute token requests to the requesting entity within the token service provider's ecosystem. Its handling during provisioning, transaction processing, and lifecycle events such as token updates or deletion is governed by the token service provider's specifications and the applicable program rules. Consult the relevant token service provider documentation to determine exactly where and how the identifier is referenced in the flows you support.
Should the Token Requestor ID be treated as cardholder data or sensitive authentication data?
A Token Requestor ID identifies a requesting entity and is distinct from cardholder data such as the PAN and from sensitive authentication data such as full track data, card verification values, and PINs. It should not be assumed to carry the same storage restrictions that apply to sensitive authentication data. Determine the appropriate handling and protection for this identifier based on your data classification, the token service provider's requirements, and how it is used in your environment.
What should we clarify with our token service provider before implementing with a Token Requestor ID?
Clarify how the identifier is assigned and managed, how it interacts with token provisioning and lifecycle operations, what protection and handling expectations apply to it, and how the overall tokenization design affects your PCI DSS scope and validation. Because provider specifications and applicable network rules vary by provider and region and can change, confirm current requirements in the provider's published documentation rather than relying on general assumptions.
Common misconceptions
A Token Requestor ID is itself sensitive authentication data or cardholder data that must never be stored.
The Token Requestor ID identifies a requesting entity within a tokenization scheme and is distinct from cardholder data (such as PAN, cardholder name, expiration date, service code) and from sensitive authentication data (such as full track data, CAV2/CVC2/CVV2/CID, PINs and PIN blocks). Sensitive authentication data must not be stored after authorization even when encrypted; that prohibition concerns the underlying data, not this identifier. How associated tokens and any linked data must be handled depends on the implementation and applicable requirements.
Having a Token Requestor ID and using network tokens automatically removes a system from PCI DSS scope.
Tokenization can reduce scope, but its effect depends on how the tokenization is implemented and validated, not on the label or the presence of an identifier. Scope reduction must be assessed against the current published PCI DSS and the specifics of the environment, and readers should confirm applicable requirements against the standard in effect rather than assuming a fixed requirement number.
A Token Requestor ID authenticates the cardholder or prevents fraud.
The Token Requestor ID identifies the entity requesting tokens; it is not a cardholder authentication mechanism. Cardholder-focused controls such as EMV chip authentication, 3-D Secure, strong customer authentication, and multi-factor authentication address different risks at different points in a transaction, and no single control eliminates fraud.
Best practices
Treat the Token Requestor ID as an entity identifier within the tokenization scheme, and document how it maps to the token requestor and its intended use cases and domains.
Do not rely on the presence of a Token Requestor ID as evidence of PCI DSS scope reduction; validate the tokenization implementation against the current published standard and confirm applicable requirements rather than assuming a fixed requirement number.
Keep tokenization concepts distinct from encryption, truncation, masking, and hashing in policies and data-flow diagrams, and record which technique protects which data element and how its effect on scope was validated.
Continue enforcing the prohibition on storing sensitive authentication data after authorization, even when encrypted, independent of any tokenization identifiers in use.
Coordinate with the token service provider on registration, issuance, and revocation processes for the Token Requestor ID, and maintain records of the associated domain or use-case constraints.
Layer cardholder authentication controls (such as EMV, 3-D Secure, strong customer authentication, or multi-factor authentication) where appropriate, recognizing that a Token Requestor ID does not authenticate cardholders or eliminate fraud.