Update (2014-10-19). The discussion of tokenization in this post is based on an interpretation of the EMV Tokenisation specification that I now think is not the intended one. See the white paper Interpreting the EMV Tokenisation Specification for an alternative interpretation.
Update (2014/09/24). Apple Pay must be using the EMV contactless specifications, which are a substantial departure from the EMV 4.3 specifications. PLEASE SEE THIS MORE RECENT POST.
After reading Apple’s press release on Apple Pay, I naively believed that Apple had invented a new protocol for credit and debit card payments. In my previous post I speculated on how Apple Pay might be using the device account number, one-time unique number and dynamic security code mentioned in the press release. But in a comment, Brendon Wilson pointed out that Apple Pay must be using standard EMV with Tokenization, since it uses existing contactless terminals, as shown in a demonstration that he sent a link to. I agree, and after spending some time looking at the EMV specifications, I believe that the device account number, one-time unique number and dynamic security code of the press release are fanciful names for standard data items in the specifications.
I’ve seen a Bank Innovation blog post that tries to explain how Apple Pay works in terms of EMV and Tokenization. But that post is inconsistent, saying sometimes that the terminal generates a transaction-specific cryptogram, and other times that the cryptogram is already stored in the iPhone when the consumer walks up to a checkout counter.
One way of explaining how EMV-plus-Tokenization works is to consider the evolution from magnetic strip cards to cards with EMV chips and then tokenization.
Magnetic strip transactions
In a magnetic strip transaction, the terminal reads the credit or debit card number (a.k.a. as the Primary Account Number, or PAN) and the expiration date from the card and assembles a transaction authorization request that contains the card number and expiration data in addition to other data, including the transaction amount. The terminal sends the request to the acquiring bank, which forwards it to the issuing bank through a payment network such as VISA or MasterCard. If appropriate, the issuer returns an approval code, which reaches the merchant via the payment network and the acquiring bank.
At the end of the day, the merchant sends a batch of approval codes to the acquiring bank for clearing. The acquiring bank forwards each approval code to the appropriate issuing bank via the payment network and credits the merchant account after the issuing bank accepts the charge and the transaction amount is received by the acquiring bank from the issuing bank.
EMV transactions
When an EMV chip is used instead of a magnetic strip, the transaction process changes as follows. The terminal sends transaction data including the transaction amount to the chip in the card, which returns a response indicating whether the transaction is to be rejected, accepted offline, or processed online by submitting it to the issuer for approval.
(In the context of EMV, an “online transaction” is an in-store transaction that is approved by the issuing bank reached over some network. To avoid confusion, I will use the term “web transaction” or “web payment” to refer to a transaction where the user enters credit card data into a web form.)
The chip’s response includes a cryptogram. Confusingly, the term cryptogram has two different meanings in the EMV specifications. Formally, a cryptogram is a symmetric signature, which takes the form of a message authentication code (MAC) calculated with a key shared between the chip and the issuing bank. (Strictly speaking, each MAC is computed with a different key derived from a permanent shared key and a transaction counter.) But informally, the term cryptogram is also used to refer to a message containing the MAC, such as the response from the chip to the terminal, and a cryptogram is said to be of a particular type, indicated by an acronym such as AAC, TC, ARQC or ARPC, determined by a Cryptogram Information Data byte included in the message.
To indicate that the transaction is to be accepted offline, the chip sends the terminal a Transaction Certificate (TC) cryptogram, while to indicate that an authorization request is to be sent to the issuer, the chip sends the terminal an Authorization Request Cryptogram (ARQC). In both cases the MAC is computed on data that includes the transaction amount and other transaction data as well as terminal and application data. However, the card number and expiration date are not included in the MAC computation.
If it receives an ARQC cryptogram, the terminal sends an authorization request including the cryptogram (i.e. the MAC) to the acquiring bank, which forwards it to the issuing bank via the payment network. The issuer responds with a message that follows the same route back to the merchant and includes an Authorization Response Cryptogram (ARPC), signed with the same key as the ARQC cryptogram. The terminal forwards the ARPC cryptogram to the chip, which sends back a TC cryptogram.
Whether the transaction is authorized offline or online, the merchant includes the TC cryptogram received from the chip in the funding request that it sends to the acquiring bank at clearing time. The TC plays the role played by the approval code in magnetic strip processing. It is forwarded by the acquiring bank to the issuer via the payment network.
Tokenized transactions
Tokenization replaces the credit or debit card number and expiration date with numeric codes of same length, called a payment token and a token expiry date respectively. Separate ranges of numeric codes are allocated so that no payment token can be confused with a card number. A Token Service Provider maintains the mapping between card numbers coupled with their expiration dates and payment tokens coupled with their expiration dates.
Reliance on the token service provider means that tokenization can
only be used for online transactions.
[Update. As explained in Shaun’s comment, there is no
reason why offline transactions cannot use tokenization.]
Only the issuer and the payment
network see the true card number and expiration date. The acquiring
bank, the merchant and the user’s device (which may be a card with a
chip, or a mobile device) only see the payment token and expiration
date. Back-and-forth translation between card data and token data is
effected by the token service provider upon request by the payment
network. Translation does not invalidate cryptograms, because
cryptograms do not include the card number and expiration date.
At transaction time, the authorization request with the ARQC cryptogram includes token data as it travels from the user’s device to the merchant’s terminal, the acquiring bank, and the payment network. The payment network sends a “de-tokenization” request to the token service provider. The token service provider returns the card data, which the payment network adds to the request before forwarding it to the issuer bank. The response from the issuer bank, which carries the ARPC cryptogram, includes card data but no token data. The response goes first to the payment network, which replaces the card data with token data obtained from the token service provider, before sending the response along to the acquiring bank, the merchant, and the user’s device.
At clearing time, the merchant sends token data along with the TC cryptogram to the acquiring bank, which forwards them to the payment network. The payment network asks the token service provider to de-tokenize the data, then forwards the card data and the TC cryptogram to the issuing bank.
The tokenization spec allows the role of token service provider to be played by the issuing bank, the payment network, or a party that plays no other role in transaction processing. According to the Bank Innovation post, it is the payment network that plays the token service provider role in Apple Pay.
The tokenization spec mentions a token cryptogram. This cryptogram is different from the others, and does not replace any of the others. Its purpose is to help the token service provider decide whether it is OK to respond to a de-tokenization request and reveal card data. It is computed with a symmetric key derived from data shared between the user’s device and the token service provider. It is sent along with a transaction authorization request from the user’s device to the merchant’s terminal, the acquiring bank and the payment network, which includes it in the de-tokenization request to the token service provider.
According to the EMV specs, the token cryptogram may also be forwarded by the payment network to the issuer, which can take it into account when deciding whether to authorize the transaction. However, the issuer cannot verify the authenticity of the token cryptogram, since it is signed with a key that the issuer does not have.
Offline data authentication
Now I need to go back to the pre-tokenization EMV specs and describe the concept of offline data authentication, which refers to the direct authentication by the terminal of data sent by the card, as part of an offline or online transaction. The EMV specifications require cards that can perform offline transactions to support offline data authentication, while such support is optional for cards that only perform online transactions. Offline data authentication takes place when both the card and the terminal support it.
Offline data authentication comes in three flavors, called SDA, DDA, and CDA.
In Static Data Authentication (SDA), the card provides the terminal with an asymmetric signature on static card data. The signature is computed once and for all by the issuer when the card is issued and stored in the card. The issuer has an RSA key pair. The private key is used to compute the signature, and the public key is included in a certificate issued by a certificate authority (CA) to the card-issuing bank . The issuer’s certificate is also stored in the card and sent to the terminal along with the signature. (The issuer’s private key is not stored in the card, of course.) The terminal uses the public key in the certificate to verify the signature, and the public key of the CA, which it is configured with, to verify the CA’s signature in the issuer’s certificate. Notice that the card does not have a key pair.
In Dynamic Data Authentication (DDA), the card has its own key pair, which is stored in the card when the card is issued. (Cryptographic best practice calls for a key pair to be generated within the cryptographic module where it will be used, but card firmware may not have key-pair generation functionality.) The card provides the terminal with an asymmetric signature computed with the card’s private key on data including a transaction-specific random challenge sent by the terminal. The card sends the signature to the terminal together with a certificate for the card’s public key signed by the issuer and backed by the issuer’s certificate, which the card also sends to the terminal.
In Combined DDA / Application Cryptogram Generation (CDA), the
data signed by the card additionally includes the cryptogram that the
card sends to the terminal.
[Update: The data that is signed also includes transaction data.
Transaction data is thus signed twice, with a symmetric signature (the cryptogram)
and an asymmetric signature. The CDA asymmetric signature provides non-repudiation,
although non-repudiation is not discussed in the EMV specfications.]
Offline data authentication in a tokenized transaction
The tokenization spec does not mention offline data authentication. Recall that tokenized transactions are necessarily online transactions, and the EMV spec does not require cards that only perform online transactions to support offline data authentication.
However, nothing prevents the use of offline data authentication in a tokenized online transaction. In a non-tokenized transaction, the asymmetric signature in any of the three flavors of offline data authentication is computed on data that includes the card number and expiration date. In a tokenized transaction, it will be computed on data that includes instead the payment token and token expiry date.
Explaining the Apple press release terminology
Based on the above, the terms in the Apple press release can be understood as follows:
Device account number. The press release says:
When you add a credit or debit card with Apple Pay, the actual card numbers are not stored on the device nor on Apple servers. Instead, a unique Device Account Number is assigned, encrypted and securely stored in the Secure Element on your iPhone or Apple Watch.
Clearly, the device account number must be what the Tokenization spec calls the payment token.
One-time unique number. The press release also says:
Each transaction is authorized with a one-time unique number using your Device Account Number …
The one-time unique number must be the ARQC cryptogram that is sent to the issuer as part of an authorization request.
Dynamic security code. The press release goes on to say:
… and instead of using the security code from the back of your card, Apple Pay creates a dynamic security code to securely validate each transaction.
This is puzzling, since the card’s security code is not used for in-store transactions, is not encoded in a magnetic strip, and is not stored in an EMV chip. It is only used for payments by phone or web payments. So nothing can be used instead of the security code for in-store transactions.
I conjecture that the term dynamic security code has been invented by an imaginative security-marketing guru to refer to an asymmetric CDA signature sent by the user’s device to the merchant’s terminal. We have seen above that CDA is not precluded by the EMV spec for online transaction. It would make sense for Apple Pay devices to provide CDA to merchant terminals, because that would increase security and could be useful to merchants. A merchant could use a CDA signature as evidence when contesting a chargeback, because an asymmetric signature provides non-repudiation. The signature would be on data including the payment token rather than the card number, but in a repudiation dispute the token service provider could supply the card number.
If Apple Pay devices implement CDA signatures, and if all terminals used with Apple Pay make use of them, then the concerns about the use of symmetric instead of asymmetric signatures that I raised in the previous post are eliminated. But other security concerns remain. In the next post I will restate those remaining concerns, taking into account new information in a MacRumors blog post on Apple Watch that was also referenced by Brendon Wilson in his comment. (Thank you, Brendon!)
The “dynamic security code” is very likely a reference to the CVC/CVV3 used when a “legacy” NFC transaction is performed (because the payment system only supports “dumb”, unidirectional magnetic stripe transactions).
Basically, what happens is that the NFC terminal issues a random challenge to the payment card; the card computes a cryptographic MAC over that challenge and a transaction counter and returns that to the terminal. Because legacy magnetic stripe POS systems don’t know about NFC, the result is included in the magnetic stripe data in place of the CVV; thus the name CVV3 or “dynamic CVV”. The scheme (and an attack on it) is explained nicely in this paper.
All this is assuming that Apple in fact supports legacy payments over NFC; they might as well only support EMV, in which case “dynamic security code” would be a fancy name for the cryptogram as you suspected. One piece of evidence is that in the Apple Pay demonstration video, the iPhone instantly shows a notification that includes the payment amount.
Since only EMV, but not the legacy protocol transmits the transaction data to the card/phone, either the demonstration was performed using an EMV-capable terminal, or the payment details are transmitted via some other way, possibly push notifications? (This would contradict the statement that Apple doesn’t know about the transaction details, though – except if the notification were encrypted to the secure element…)
Thank you very much for your comment and the link to the Roland-Langer paper, which was very useful. After seeing your comment, and the other comment also mentioning CVV3, I did a lot more reading. I looked at the EMV contactless specifications, which I had neglected to look at before. I’ve written another post explaining what I’ve found out.
I agree with you that the “dynamic security code” of the Apple press release must be CVV3 (or CVC3 as it’s called in book C-2 of the contactless specifications). I’ve actually found an explanation of the fact that the phone is able to show the transaction amount. CVC3 is used in the so-called mag-stripe mode of the contactless specs. In mag-stripe mode the authorization request sent to the issuer is like the one sent by a magnetic-stripe card with CVC3 instead of CVC1; but before the authorization request is sent, there is a preliminary exchange of messages between the user’s device (contactless card or mobile phone) and the point-of-sale (POS). That preliminary exchange follows EMV 4.3 protocol, and includes a GET PROCESSING OPTIONS command, sent by the POS to the user’s device. The GET PROCESSING OPTIONS command usually includes, as a command argument, the amount of the transaction; I believe this is because the processing options are dependent on the amount. Thus Apple Pay on the mobile phone knows the amount of the transaction and can enter it into the log and show it to the user. On the other hand, I don’t think Apple Pay is notified of the response to the authorization request, since the phone may no longer be in the NFC field when the response arrives. So if the transaction is declined, that will not be reflected in the log.
Very interesting presentation indeed. I am still wondering what is preventing the Android phone to emulate directly the contactless EMV mag-stripe payment done by the Java card applet ? Is it because the NFC reader can only communicate with the Secure Element ?
The Android app has the pre-computed CVC3 (mapped to challenge nonce), transaction counter and payment card info. Why does it still need to go through a Java card applet inside the SE , couldn’t it be achieved with HCE compliant phones ?
Actually, nothing prevents apps running under Android from emulating the behavior of an EMV contactless card in mag-stripe mode (nor in EMV mode, for that matter). I believe the intention of HCE is precisely that. In HCE, the NFC controller communicates directly with the Host CPU, according to the Android developer documentation.
I wouldn’t refer to the CVC3 as being “pre-computed”. Since it depends on the challenge from the POS, it must be computed after the phone enters the NFC field and receives the challenge. An HCE payment app must have a shared secret with the issuing bank, which is used to compute the CVC3 from the challenge and the transaction count. The secret must be provisioned by the issuing bank.
An advantage of storing payment credentials such as the shared secret and payment token in a secure element, as Apple Pay does, is that the secure element may provide physical tamper resistance, for protection against an adversary who steals the phone. There is also a need to protect a credential activation fingerprint or PIN against being intercepted or phished by malware. This can be accomplished by running the payment application in a Trusted Execution Environment (TEE) that provides a Trusted User Interface. I assume that’s what Apple does: the Apple Pay payment app is probably running in an ARM Trustzone TEE, which Apple has referred to in the past as the Secure Enclave, and which provides a trusted path to the Touch ID sensor. This is not incompatible with storing the payment credentials in a secure element controlled by, or accessible from, the TEE. (In fact, the GlobalPlatform TEE specs include a TEE Secure Element API for doing just that.) With a pure HCE solution you do not get protection against physical capture or against malware.
Btw, it is possible to protect against physical capture using “virtual tamper resistance” instead of the physical tamper resistance provided by a secure element. If you are interested in that, I’ve just put online an animated PowerPoint that I presented yesterday at the GlobalPlatform TEE conference on that topic, with speaker notes.
Dynamic CVV:
http://randomoracle.wordpress.com/2012/09/11/cvv3-demystifying-credit-card-verification-part-2/
Apple essentially did nothing but implement a standard. Still, bodes well for EMV adoption in the US.
Thank you very much for the link, which was very useful. I agree that Apple is just implementing a standard. After doing a log more reading, I think the specific standard is the EMV Contactless Specification, in mag-stripe mode, profiled for mobile phone use. I explain this in more detail in a more recent post.
US retailers and the acquiring banks do not yet support EMV. Contactless in the US uses Magnetic Stripe Data (MSD). As there is no dynamic authentication as part of an MSD contactless transaction it is very easy to add Apple Pay to this infrastructure.
Adopting Apple Pay over EMV would be much more complex involving mobile provisioning of the customers card. Each Bank would have to provision their cards independently as its highly unlikely that Visa / MasterCard would give Apple access to their Private Keys in order to dynamically provision a regular bank card on the device. This normally has to be done by the issuing bank.
The only way I can see this working over EMV is for Apple to act as a card issuer and provision an Apple card over the NFC chip. This will then be translated to the Banks Card number as part of the transaction flow. However, your bank will not have authenticated the transaction over EMV, Apple will have done. How this will work when it comes to disputes is, as yet, unknown.
Thank you for your comment. I agree that the EMV protocol as I explained it in this post is probably not what Apple Pay uses. However, after looking at the EMV contactless specifications, I think I can fine tune a bit what you say in your comment.
I agree that contactless transactions in the US use magnetic stripe data but I wouldn’t say that there is no “dynamic authentication”. The magnetic stripe data is modified to include the dynamic CVC3 code, mentioned in other comments, instead of CVC1. As I explain in a more recent post, the CVC3 code is a signature on a random nonce and a transaction count, which are included in discretionary track data fields. The CVC3 signature is computed with a secret key that is shared between the user’s device (the mobile phone in the case of Apple Pay) and the issuer. The issuer provisions this secret key to the mobile phone. I believe a provisioning arrangement with issuing banks was mentioned in the Cupertino event when Apple Pay was introduced.
The contactless specifications include both a “mag-stripe mode” and an “EMV mode”. Although Apple Pay may not be using the EMV mode now, it may very well use it in the future, as an infrastructure supporting EMV contact transactions is phased in in the US (which is happening right now). In EMV mode the user’s device produces both symmetric signatures (the ARQC and TC cryptograms) that are verified by the issuer, and an asymmetric signature that is verified by the terminal in what is called “offline data authentication”. Offline data authentication comes in three flavors: SDA, DDA and CDA. In SDA the asymmetric signature is computed with the issuer’s private key, but it is computed by the issuer on static data when the user’s device is provisioned, not on dynamic data at transaction time; the issuer gives the signature to the device, not the private key. In DDA and CDA the signature is computed with a private key stored in the device, but this is a private key that is specific to the device, not an issuer-wide private key. So Apple Pay will be able to implement EMV mode without requiring the issuer to store an issuer-wide private key in the mobile phone, or surrender such a private key to Apple.
Mastercard Paypass and Visa Paywave operate slightly differently to the EMV Chuip specs, specifically After the going online the chip does not see the ARPC from the host as the chip has likely left the contactless field (so you don’t need to hold the card in the field when you go online.). So you don’t get a TC for online transactions. The host validates the ARQC. Only for a Offline could you get a TC
I can’t see why Tokenization means online only. What stops the token transaction been approved offline and then sent up when the terminal settles with the acquirer?
From my way of thinking about this it feels like a standard Payapss/Paywave transaction with the Token in the TRACK2_EQUIVALENT_DATA tag. One thing I’d wonder about is the CVM (Customer Verification Method) which is Online PIN, Signature or None. I’d presume that the Apple Pay will have either a no CVM or a new one (Mobile authorised.) How some terminals will handle this will be interesting, I beleive unattended terminals required online PIN as minium (once the transaction is over a certain value)
Thank you very much for your comment.
I think you are right that there can be no TC in online contactless transactions in EMV mode. And that’s consistent with Section 3.4.3 of book C-2 of the EMV Contactless Specifications, which I’ve been looking at.
You’re also right that there is no reason why offline transactions could not be tokenized. I’ve updated the post to reflect that, pointing to your comment.
Regarding CVM, I’ve seen in the C-2 book that mobile phones are treated differently from cards, and there is a special provision for delegating customer authentication to the phone. See Section 3.8.
After doing a lot more reading, I’ve written another post that takes into account the contactless specifications, which I hadn’t looked at when I wrote this post. If you have any comments on that, they would of course be most welcome.
Thank you for the information. So as we move forward as a card issuer preparing for EMV, should we make the decision to go with contactless specifications or how can we move forward with the reissuance of EMV but at the same time stay prepared for the whole “tokenization” world? What would be our best deciding factors?
Thank you for your questions. Here are some thoughts:
1. As I’m sure you know, you need to issue cards with a contact chip in order to benefit from the liability shift that will take place on October 1, 2015. After that date liability for fraud with a counterfeit card will shift to the merchant if the merchant has a point of sale that can only read magnetic stripes and your customer presents a card with a contact chip. A chip card with a contactless interface but no contact interface WILL NOT shift the liability, according to this slide set from VISA.
2. Sooner or later, public transportation in the US will accept NFC payments as is the case now in other countries. That would be a reason for issuing cards with both a contact and a contactless interface.
3. As I explain in a more recent post, there are two kinds of tokenization. In tokenization of the first kind, the credit card number is replaced with a merchant-specific or transaction-specific token by the merchant’s processor when the authorization comes back from the issuer; this allows the merchant to store the token instead of the card number, reducing risk and facilitating PCI compliance. Tokenization of the first kind is a private matter between the merchant and the processor that does not involve the banks or the payment network. In tokenization of the second kind, card data (number and expiration date) is replaced with token data (number and date) in the user’s device, whether a phone or a card. The same token is used for all merchants.
4. Tokenization of the second kind is desirable for contactless payments. Otherwise the card data is sent over the air to the point of sale, and can be sniffed from a considerable distance (up to one meter if transmitted by a card, up to 10 meters if transmitted by a phone). After they have been sniffed, they can be used to make web payments, either to online merchants that do not ask for the security code, or to any online merchant after guessing or otherwise obtaining the security code. When tokenization is used in a contactless transaction, the token data is transmitted to the point of sale instead of the card data. Token data cannot be used to make web payments because the token is not a valid card number. (It belongs to a range of numbers reserved for tokens rather cards.) Preventing card data sniffing would be a reason for storing token data in the chip of a contactless card and using it instead of card data for contactless transactions (while printing the card data on the card and encoding it in the magnetic stripe).
5. Tokenization of the second kind is specified by the “EMV Payment Tokenisation Specification Version 1.0” of March 2014. We’ve been looking in more detail at this specification, and have come to realize that it is badly flawed. I will write a blog post to report our findings in a few days. Hopefully the specification will be fixed. For reasons that will become clear after I write the post, I would recommend getting ready to implement tokenization by being your own token service provider. Update. The blog post is now available: Making Sense of the EMV Tokenisation Specification. There is also a longer white paper: Interpreting the EMV Tokenisation Specification.
6. Of course you may want to support Apple Pay and whatever tokenization it uses, depending on whether it takes off with merchants and whether your customers insist on it. I would also recommend considering HCE, which you could offer to your customers on Android devices without having to negotiate with Apple.
A very informative post for tokenization. The company where I work is moving towards tokenization but there were challenges that was identified. I just wanted to get your idea on how tokenization (the first kind) is handling offline scenarios where the merchant is unable to contact the token service provider (which may also be the acquirer) for a token. If this case happens, does it mean that the merchant has to store the encrypted card data instead of the token? Or does it make sense to just don’t accept the payment when offline scenarios like this (which may not happen a lot) happen to avoid compromising the card data? Any ideas is much appreciated. Thanks!
I think it should be OK to store the encrypted card data for a brief period of time until you can contact the token service provider. (I assume you will be able to contact the provider no later than close of business, when the day’s authorizations are usually submitted for settlement.) If the card data is encrypted with a public key and can only be decrypted with the corresponding private key held by the token service provider, the risk of compromise should be increased minimally, if at all, by storing the encrypted data for a few hours. But you should ask the token service provider, which should be able to tell you if storing the encrypted data is acceptable. You should also ask the acquiring bank, if tokenization is not provided by the acquiring bank itself. And you should make sure that storing the encrypted data does not break any legal agreements or increase your liability. HTH.
See “EMV Payment Tokenization Specification v1.0”, 9.2 Use Case 1: Mobile NFC at Point of Sale, step 1.:
“a. Payment Token will be passed in the existing PAN field.
b. Token Expiry Date will be passed in the PAN Expiry Date field.
c. Token Cryptogram will be generated based on the Token data elements and will be passed in the Chip Cryptogram field. (The cryptogram may be a full chip cryptogram, or an abbreviated Track 2 equivalent cryptogram)
d. Token Requestor ID will be passed as an optional field
e. All other contactless data elements will be created and passed following the contactless data standards.”
Although this does not provide unique reference to EMV tags (or ISO8583 fields), it can easily be interpreted as follows:
a. tag 5A
b. tag 5F24
c. tag 9F26 or tag 57 (CVV/CVC3 in issuer discretionary data)
d. tag 9F19 (obtained via GET DATA, not sure about this)
This matches to the results I got during testing Apple Pay/Apple Wallet against EMV capable NFC readers.
Don’t know, what “Token Cryptogram will be generated based on the Token data elements” means. Maybe, it should rather be read as “transaction data elements”, which makes much more sense for me…