TID and RID

FAST uses TID (Transaction thread Identifier) and RID (Record Identifier) to differentiate between transactions and their message types. We explain these in further detail below.

TID: Transaction thread Identifier

TID is the unique identifier for transaction threads (auth, auth advisement, reversal, settlement etc.) in order to link all the associated transaction messages to one transaction.

TID is unique per token/card and should not be treated as unique across all tokens/cards. Clients must match a transaction using both the TID and the corresponding token.

The TID of the original transaction is prepared by using the DE7, DE11 and DE32 of the request as a bigint data type whereas the ensuing transactions are assigned the same TID to its original transaction.

As an optional configuration, the original TID can be generated using a sequentially incrementing value (left padded with 0 to total 19 characters) to mitigate any duplication of TID, in cases where TIDs must be unique across all tokens/cards.

DE 90 Original Data Elements can be used to identify the original TID against reversals. We have observed in the past that this field is unreliable in the case of Visa. We currently use the card token, mtid, de37, and de32 to identify the original transaction.

RID: Record Identifier

RID is the unique identifier assigned to each unique message associated with a transaction. Its use allows clients to identify the unique message types, any replayed messages, and multiple messages of one transaction.

For authorization, it is a sequentially incrementing value for every transaction in an environment.

For presentment, it is prepared by the combination of msg_id, file_id and a static number to make it unique.

Add_Ref_RID: Additional Reference RID

Currently only applicable for MADA

Authorization:

Reference RID in order to link the follow-up transactions (such as pre-auth increment, advisements etc.) to its original transaction. So the RID of the original transaction and Add_Ref_RID in follow-up authorization transactions will be the same.

Presentment:

Reference RID in order to link the presentment to its associated original authorization transaction. The RID of the original transaction and Add_Ref_RID of the associated presentment will be the same.

Architectural flow

Below is shown the architecture of possible transaction flows along with the possible values of the RID and Add_Ref_RID in the transaction messages. We do this by using the following:

• TID of the associated transaction as XXXXX,
• RID of auth as RRRRx,
• RID of presentments as PPPPx
• the value of authorization id as AAAAx.

Single auth, single presentment

In this single authorization transaction, we are considering the transaction is assigned the TID XXXXX and the RID RRRR1 which is sent to the client's FAST endpoint for them to take the final decision regarding the authorization. Here we are assuming that the client is approving the transaction and Banking.Live is responding to the network with approval along with the mandatory authorization ID as AAAA1. So when the presentment of this authorization is received along with the authorization id AAAA1 to link this presentment to its original authorization, Banking.Live prepares the FAST presentment request with the same TID as that of the auth (to show the thread linkage), RID value of the original auth to the Add_Ref_RID of the presentment as RRRR1 and RID of its own as PPPP1 in order to uniquely identify this presentment request.

Single auth, multiple presentments

The single authorization transaction here is assigned the TID XXXXX, RID RRRR1 and the authorization ID AAAA1. So, when the presentment to this authorization is received in the form of multiple partial presentments, each such presentment will receive the same authorization ID as AAAA1 and will be associated with the same authorization. Hence, each partial settlement will match the same original auth TID of both partial presentments, equal to that of the original auth (XXXXX), Add_Ref_RID of both partial presentments as RID of original auth (RRRR1) and the RID of each partial presentment as a unique identifier to distinguish it from other presentments. Therefore, the RID's assigned to these presentments are PPPP1 and PPPP2.

Pre-auth, pre-auth, single presentment

The original pre-auth transaction below is assigned the TID XXXXX, RID RRRR1 and the authorization ID AAAA1. When the pre-auth completion advisement message to the earlier original pre-auth transaction is received having the same authorization ID (DE38) AAAA1, the advisement is assigned the same TID as its original auth and the RID is assigned a unique value in order to distinguish it separately. Therefore, the assigned values of RRRR1 and RRRR2 for pre-auth and pre-auth completion are used.
When the presentment to this transaction is received with the authorization ID AAAA1, the TID and RID of the original pre-auth are assigned to the TID and Add_Ref_RID of the presentment as it links to the original pre-auth based on the authorization ID.

Multiple pre-auth, single presentment

The original pre-auth transaction below is assigned the TID XXXXX, RID RRRR1 and the authorization ID AAAA1 and when the associated incremental pre-auth to the previous pre-auth is received, the same TID as the original pre-auth ID is assigned but the RID and authorization ID are made unique in order to identify the transaction uniquely. Therefore, it is assigned as RID = RRRR2 and authorization ID = AAAA2.
Now, when the single presentment for both the auth messages (the accumulated amount of both auth) is received, it can have the authorization ID of either of the pre-auth i.e., either original pre-auth or incremental pre-auth. But normally the authorization ID of the later authorization is expected. Therefore, based on whether the authorization ID of the former or later pre-auth is received, the RID value of that auth will be assigned to the Add_Ref_RID of the presentment. In the example below, we have assumed that the authorization ID of the incremental pre-auth is received hence the Add_Ref_RID is assigned AAAA2 whereas TID is assigned to the same authorization and RID is created as a unique value as in previous examples.

Multiple pre-auth, partial reversal, single presentment

The RID, TID and Add_Ref_RID assigning criteria are similar to those above, even when the multiple pre-auth transactions are followed by a partial reversal. The partial reversal will have the same TID assigned with the unique RID (RRRR3 in this case) along with the partial amount to be reversed. The presentment will have the TID of all the pre-auth and reversal messages, the RID will be unique to any other existing presentments and the Add_Ref_RID will be assigned with the RID value of that authorization to whichever the authorization ID received in the presentment matches to, which in this example matches to the first original pre-auth, hence Add_Ref_RID is assigned the value RRRR1.

TID and RID sample messages

Sample messages showcasing TID and RID are located can be found in the Sample FAST messages guides.