Annex IV

Guidance on the Unique Transaction ID (UTI)

Version	Effective Date
ANNEX IV – Guidance on the Unique Transaction ID (UTI) 2.2	13 March 2024

Please read carefully The Agency developed the Guidance on the Unique Transaction ID (UTI) and the excel file for the UTI generation in conjunction with its stakeholders following an intense consultation of the industry. Market participants should bear in mind that it is their obligation to comply with REMIT and it is their obligation to make sure that the Agency receives the correct UTI in the correct format for their transactions as required by Commission Implementing Regulation (EU) No 1348/2014. This should be the unique identifier for a transaction (UTI) as assigned by the organised market place of execution or by the two market participants in the case of bilateral contracts to match the two sides of a transaction. Whilst for executions at organised market places, the UTI is already defined by the organised market place, market participants have to agree which form of a UTI they will use before reporting any bilateral contract. This therefore includes determining the approach that they will use to define which entity generates the UTI. Accordingly, the generation and usage of an agreed UTI for bilateral trades that take place outside an organised market place may be needed. The Agency has already made available guidance on the UTI in its Transaction Reporting User Manual (TRUM), but would like to facilitate the UTI generation for bilateral contracts as much as possible for the benefit of market participants. This is why the Agency has developed and made public an ACER algorithm which would enable market participants to generate a UTI from the economic terms of the bilateral trade. Please note that it is not mandatory to use the Agency’s UTI generator. It only aims at providing another possibility for the UTI generation for bilateral contracts. Eventually, market participants bear the responsibility of reporting both sides of the bilateral trades and contracts with a unique transaction ID. For a few complex contracts this guidance and the UTI generator tool may need to be updated in the future. Where market participants feel that this guidance and the UTI generator tool provided by the Agency may not fully satisfy their needs, they should generate and agree on a UTI as indicated in the TRUM. It is important to stress that it is ultimately the market participants’ responsibility to make sure that the Agency receives the correct UTI in the correct format for their transactions as required by Commission Implementing Regulation (EU) No 1348/2014. The Agency aims at continuing its cooperation with the industry to update this guidance and the UTI generator tool as required. If you have any question related to this document, please use the REMIT query form https://support.acer-remit.eu/forms/remit-query-form.

ACER’s Unique Transaction Identifier generator tool

Unique Transaction Identifiers (UTIs) can be created in different ways; to help provide some consistency in the generation of UTIs, the Agency has tested a solution and believes it is simple and usable by the vast majority of reporting parties.

The generation is based on using a hash function (BASE 64 SHA256) which allows the creation of a UTI value from the economic terms of a trade or contract.

Please note that some market participants, while testing the UTI generator, have experienced an issue due to missing VBA functionality under Windows 10. Please note that the UTI generator is functioning under Windows 10 after activating .NET Framework 3.5 (includes .NET 2.0 and 3.0).

It is important that the reporting parties use the terms agreed at the time of trade execution/contract agreement rather than those that are stored in the market participants’ trade/contract capture systems. However, some normalisations have been introduced in the version 2 of the UTI generator tool to cope with some mismatches observed.

The Agency is offering one solution only and it is up to market participants to assure the REMIT compliance with regard to UTI and implement this guidance according to their IT needs. The Agency’s UTI generator is based on an excel spreadsheet which is available on the ACER website here.

The ACER algorithm is based on the concatenation of economic terms included in the trade/contract and standardised to 45 characters. The UTI generation works in the following steps:

1. The relevant information is entered into a spreadsheet or any other application capable of running the required task, e.g. web GUI, java etc.;
2. The entered data is normalised where applicable as agreed with the industry.
3. The relevant information is concatenated first, then “hashed” and thus an UTI is generated.

This process works identically for both reporting parties if the reporting parties use the same input data and it may make sense for market participants’ IT departments to build the UTI generator into their local trading system enabling the UTI generation whenever they enter a trade; but this decision should be taken by each market participant in coordination with their counterparties.

The input text comprises the data elements taken from the REMIT Table 1 example below:

Buyer's ACER code	C0643778W.EU
Seller's ACER code	C06AG978W.EU
Contract Type	SP
Commodity	EL
Settlement	O
Date of the Trade	2014-11-21
Price	5.35
Currency	EUX
Quantity Volume (Field 40)	24000
Quantity Unit for Field 40	KWh/d
Delivery Point or zone	10YCB-EUROPEU--8
Delivery Start Date	2015-01-01
Delivery End Date	2015-01-31

When data fields are formatted, normalised and concatenated in the right order as a string, the result is the following:

C0643778W.EUC06AG978W.EUFWELP2014-11-210.00223EUR1.0000000000MW10YCB-EUROPEU--82015-01-012015-01-31

Please note that the concatenated value contains normalised values (characters highlighted in yellow) following the instructions described in sections below and are not just a copy of the input.

Once the input has been hashed, the result is the following: YwBycOVBTzf2d1nWsAF3CSNz1nbeF4TBNOKz0tHM26wC

The output value of the hash function would be the following UTI: YwBycOVBTzf2d1nWsAF3CSNz1nbeF4TBNOKz0tHM26001

This is independent of the party (buyer or seller) generating the UTI values since both parties using the same data and the same algorithm will generate matching UTIs. It must be remembered that if only a minor modification is made to the input data by one party, the output value will be completely different. Both counterparts remain responsible for the generation of an identical UTI in their respective reports of the same trade.

It may be that some fields will not be available (e.g. the price for index trades) and they cannot be included in the UTI generation. However, two market participants that generate a UTI/Contract ID using the data listed in the relevant tables below would nevertheless be able to create exactly the same identifier by following this guidance.

General remarks:

• All fields are treated as text fields, even though some of them are of different original formats (e.g. Contract date, Price, Quantity/Volume and Progressive Number).
• Spaces (blanks) are not permitted since a blank character is also a character that has an effect in the UTI generation.
• Reporting parties should use the terms agreed at the time of the trade execution/contract agreement rather than those that are stored in the market participants’ individual systems

Normalisation scope

Certain fields are subject to automated format change and/or normalisation prior to concatenating, and this is why certain values within the Concatenated value will differ from the input values; these are explained in more detail within Section (1).

Field No	Field Name	Condition
23	Contract Type	Certain values should not be used for entry data, other values will be automatically changed under certain conditions in the Concatenated value. See details in Item #3 below.
26	Settlement Method	The accepted entry value of “O” will be replaced by “P” in the Concatenated value. See details in Item #5 below.
35	Price	There are several assessments applied to this field: The entered price will be automatically changed to reflect the price with five (5) decimal places, by either adding zeros, or rounding the value; - Where the price is entered in the minor unit of a currency (either EUX or GBX), the price value will be converted within the Concatenated value to reflect the price in the major unit of the relevant currency; Price will be also normalised to price per standard energy unit in the Concatenated value. See details in Item #7 below.
37	Price currency	Where a minor unit of currency is used, i.e. EUX or GBX, this will be normalised to the major unit of the relevant currency i.e. EUR or GBP only. See details in Item #8 below.
40	Quantity/volume	The quantity/volume will be normalised to a standard unit with 10 decimal places. See details in Item #9 below.
42	Quantity Unit	Standard units are agreed to be: MWh/h (MW), Therm/d, cm/day, Btu/d and MJ/d. See details in Item #10 below.

Section (1) Relevant fields to be taken into account for the generation of the UTI for the reporting of transactions with the REMIT Table 1 of the Annex of REMIT Implementing Regulation. Please see the TRUM for further details.

Table 1

#	Field No in TRUM	Field name in the Table 1 UTI Generator	Values in the Table 1 UTI Generator (example)
1	1	Buyer's ACER code	C0643778W.EU
2	4	Seller's ACER code	C06AG978W.EU
3	23	Contract Type	SP
4	24	Commodity	EL
5	26	Settlement method	O
6	30	Date of the Trade (without time)	2014-11-21
7	35	Price	5.35000
8	37	Price currency	EUX
9	40	Quantity/Volume	24000.00000
10	42	Quantity Unit for field 40	kWh/d
11	48	Delivery Point or zone	10YCB-EUROPEU--8
12	49	Delivery Start Date	2015-01-01
13	50	Delivery End Date	2015-01-31
14	n/a	Progressive Number (for equal trades on the same date)	1
15	n/a	Concatenated values	C0643778W.EUC06AG978W.EUFWELP2014-11-210.00223EUR1.0000000000MW10YCB-EUROPEU--82015-01-012015-01-31
16	n/a	Hash of the concatenated values	YwBycOVBTzf2d1nWsAF3CSNz1nbeF4TBNOKz0tHM26wC
17	31	Unique transaction ID	YwBycOVBTzf2d1nWsAF3CSNz1nbeF4TBNOKz0tHM26001

The Fields highlighted in yellow are subject to formatting and/or normalisation; e.g. Contract Type=SP, “SP” will be normalised. The yellow Value string is the normalised Concatenated value; e.g. “SP” is normalised in the Concatenated values string to “FW”.

Items #1 & #2: Field (1) Buyer's ACER code and Field (4) Seller's ACER code:

The Agency would like to avoid any inconsistent interpretations or views which may arise from an individual market participants’ perspective in terms of who is a buyer or who is the seller.

Each trade has unambiguously defined a buyer (the one who accepts a commodity or an instrument) and a seller (the one who gives up a commodity or an instrument). Therefore, Field (1) always requires the buyer's ACER code whereas Field (2) always requires the seller's ACER code irrespective of who (buyer or seller) is reporting. Please note that the code must be an ACER code and no other code (such as an EIC, LEI or BIC) is allowed.

The buyer/seller logic is available in the TRUM; please see Field No (11). Note that in the case of a floating to floating derivative, if party (A) buys a swap, party (A) pays the floating price of the first leg (or index) and party (B) pays the floating price of the second leg (or second index). In this case the two legs (indexes) of the swap should be sorted alphabetically.

For example, if party (A) and party (B) enter into a swap transaction where the financial settlement is the difference between two floating indexes "XYZ Index" and "ABC Index", (A) is the buyer of the swap if (A) pays the floating price of ABC Index and receives the floating price of XYZ Index while (B) is the seller of the swap as (B) receives the floating price of ABC Index and pays the floating price of XYZ Index.

Any deviations from the above will result in the generation of different UTIs which would therefore be invalid.

Item #3: Field (23) Contract Type:

The range of accepted values for the Contract Type is available in the TRUM. However, the value “OT” (Other) should never be used and it is not allowed to be used in the UTI generator tool.

In addition, the Agency’s UTI algorithm always replaces the following contract types:

• if contract type is "SW" and Settlement method is "P" or "O", then its value is replaced with "FW”;
• if contract type is "SP" and Settlement method is "P" or "O", then its value is replaced with “FW”;
• if contract type is "SP" and Settlement method is set to "C", then its value is replaced with “SW”;
• if contract type is “SWG” and Settlement method is “P”, then its value is replaced with "FW”;
• if contract type is “OP_FW”, “OP_SW”” or "OP_SP", then its value is replaced with “OP”;
• Please note that “AU”, “CO”, “FU” or “OP_FU” are not allowed to be used in the UTI generator tool. In the example provided within the Table 1 above the combination of the Contract type "SP" and Settlement method "O" resulted in the “FW” within the Concatenated value.

Item #4: Field (24) Commodity:

The range of accepted values for the Commodity is available in the TRUM.

Item #5: Field (26) Settlement method:

The range of accepted values for the Settlement method is available in the TRUM. However, if the Settlement method is “O” (Optional for counterparty) then its value is replaced with "P” in the Concatenated value.

This is also the case in the example provided within Table 1 where Settlement method “O” was entered by reporting party but has been replaced with "P” in the Concatenated value.

Item #6: Field (30) Date of the trade (without time):

This field should be populated in ISO 8601 standard, i.e. YYYY-MM-DD. There should be no representation of time (hours, minutes, seconds etc.) used; the field is strictly a date type field.

Item #7: Field (35) Price:

When the price of a trade/contract is known at the time of execution the value should be used for the UTI generation. Reporting parties should use the price agreed at the time of the trade execution rather than the one that is stored in the market participants’ individual systems.

The field Price has been dealt within the UTI generator tool as follows:

At first, if a price is entered that has less than five decimal places after the decimal point, the “UTI generator” will convert the price format such that there will be five decimal places used in the price field. For example ‘25.5’ will become ‘25.50000’.

If a price has more than five decimal places, the ‘round half up’ rule will apply and the price format will be converted to five decimal places before being used in the concatenation. For example entry ‘48.123455’ will be rounded to ‘48.12346’, whereas ‘48.123454’ will be rounded to ‘48.12345’.

Please use decimal point (.) as the separator.

In a second step, a value from price field will be converted to the major unit (valid for the GBX to GBP and EUX to EUR currencies only) and normalised in the price per 1 standard unit of energy family group, e.g. 1 MW (see also the conversion of Quantity to a standard unit of the family group, Item #9 below).

Price in the concatenated value is always converted to price/1unit (e.g. EUR/1 MW). This is needed to reduce the risk that for the same trade are entered different values that have the same meaning and resulting in different UTIs.

When the price of a trade is not known at the time of the UTI generation (e.g. due to a price index), the ‘Price’ field along with the ‘Price currency’ field should be left blank. The UTI generator tool will create a value of ‘0.00000’ to represent the price within the concatenation.

Please note that index price differentials are reported in Field (36) Index Value, not in Field (35) Price and they should not be used in the UTI generator.

For transactions having multiple prices then the price for the 1st time interval should be used.

All the trades below have the same price (EUR) per MW but are edited differently - different combination of the price currency and quantity unit are entered in the following fields:

#	Price	Currency	Quantity	Unit
1	53.50000	EUR	1.00000	MWh/h
2	1284.00000	EUR	24.00000	MWh/d
3	53.50000	EUR	1000.00000	KWh/h
4	1284.00000	EUR	24000.00000	KWh/d
5	5,350.00000	EUX	1.00000	MWh/h
6	128400.00000	EUX	24.00000	MWh/d
7	5,350.00000	EUX	1000.00000	KWh/h
8	128400.00000	EUX	24000.00000	KWh/d

All the above trades will have a price converted to EUR 53.5000 and the quantity will be converted to 1 MW (see Item # 9 below) in the Concatenated value.

In the example provided within the Table 1 of this document that would mean that the value for the price within the Concatenated value is calculated in the following steps:

• the price from EU cents (i.e. EUX) converted to EUR (5.35 EUX -> 0.05350 EUR) valid for the KWh/d unit;
• the conversion of the quantity volume KWh/d to the standard unit MWh/h i.e. MW is: (24000 KWh/d)/24= 1000 KWh/h which is 1 MWh/h i.e. 1MW);
• the price/1unit calculation (0.05350/24) = 0.00223 EUR per standard unit and that unit being 1 MW).

Item #8: Field (37) Price currency:

The range of accepted values for the Currency is available in the TRUM. Reporting parties should use the currency as at the time of the trade execution rather than the one that is stored in the market participants’ individual information systems.

However, in circumstances where the price is reflected in the minor unit (for example UK natural gas is traded in ‘pence per therm’), the UTI generator will convert the currency to the major unit and normalise the price to reflect this change. For example ‘51.00 GBX’ will be normalised to ‘0.51000 GBP’. This is limited to GBX-GBP and EUX-EUR currencies only.

If there is no price available as described in Item #7, then the ‘Price currency’ field should be left blank; there will not be any representation for the currency within the concatenation.

Item #9: Field (40) Quantity/Volume:

When the Quantity/Volume (capacity) of a trade/contract is known at the time of execution the value should be used for the UTI generation. Reporting parties should use the quantity/volume agreed at the time of the trade execution rather than the one that is stored in the market participants’ individual systems.

The UTI generator tool converts Quantity to a standard unit of the family group. For example:

• KW, KWh/h, KWh/d, MWh/h, MWh/d, GW, GWh/h and GWh/d are converted to MWh/h (MW);
• KTherm/d and MTherm/d are converted to Therm/d;
• mcm/d and tcm/d are converted to cm/d;
• MMBtu/d is converted to Btu/d;
• 100MJ/d, MMJ/d, GJ/d are converted to MJ/d;

The field Quantity has been dealt within the UTI generator tool as follows:

If a quantity/volume is entered as a value with less than five decimal places after the decimal point, the “UTI generator” will convert it in such a way that there will be five decimal places used in the Quantity volume field. If a value in the quantity/volume field has more than 5 decimal places, the ‘round half up’ rule will apply and the value will be normalised to 5 decimal places before using in the concatenation.

Please use decimal point (.) as the separator.

In the concatenation value, all quantity will be converted to 1 energy unit, e.g. 1 MW (see also the conversion of Quantity to a standard unit of the family group).

This is needed to reduce the risk that for the same trade are entered different values that have the same meaning. All the trades below have quantity (1 MW) but represented differently:

#	Price	Currency	Quantity	Unit
1	53.50000	EUR	1.00000	MWh/h
2	1284.00000	EUR	24.00000	MWh/d
3	53.50000	EUR	1000.00000	KWh/h
4	1284.00000	EUR	24000.00000	KWh/d
5	5,350.00000	EUX	1.00000	MWh/h
6	128400.00000	EUX	24.00000	MWh/d
7	5,350.00000	EUX	1000.00000	KWh/h
8	128400.00000	EUX	24000.00000	KWh/d

All the above trades will have a quantity converted to 1 MW in the concatenated value and the prices will be converted accordingly (see Item # 7 above).

For trades that do not have a fixed volume for the entire delivery period of the trade/contract, the volume for the first non-zero delivery period should be used for the UTI generation.

In the example provided within the Table 1 of this document that would mean that the quantity volume of 24000 KWh/d is converted to the standard unit MWh/h i.e. 1 MWh/h. Within the Concatenated value the quantity/volume is replaced by the quantity volume in the format 1.0000000000 MW.

Item #10: Field (42) Quantity Unit for field 40:

The range of accepted values for the Quantity (capacity) Unit is available in the TRUM. However, it is important to stress that both market participants should use exactly the same Quantity Unit as at the time of the trade execution rather than the one that is stored in the market participants’ individual systems.

For example, if two market participants trade UK NBP gas, they most like trade in Therms. In this case the quantity unit to be used is Therm/d and not MWh/h or any other units. Or, if two market participants trade German electricity, they most likely trade it in MWh/h; again no other unit should be used.

Only a Field (42) value contained in the list of accepted values for field 40 detailed in the TRUM can be used in the UTI generator tool and these must be entered in the same format i.e. ‘MWh/h’ and NOT ‘mwh/h’.

Standard units for which the price/1unit is calculated (e.g. X EUR per 1 MWh/h) within the Concatenated value are agreed to be MWh/h (MW), Therm/d, cm/day, Btu/d and MJ/d.

Item #11: Field (48) Delivery Point or zone:

Only EIC codes published in the “List of Accepted EICs” in ANNEX VI of the TRUM must be used. There is no automatic (built-in) normalization in the UTI generation.

This field should be populated with the EIC Y, EIC W or EIC Z for the delivery point or zone of the trade. In cases where there are more than one delivery point or zone relevant to the trade, the market participants should use the first EIC code in alphanumeric order (i.e. 0-9, A-Z) in the UTI generator tool. For example if:

• EIC 10YCB-EUROPEU—18 and 16YCB-EUROPEU—9 are in the contract then 10YCB-EUROPEU—18 will be used for the UTI generator; or
• EIC 22YCB-EUROPEU—18 and 11YCB-EUROPEU—9 are in the contract then 11YCB-EUROPEU—18 will be used for the UTI generator.

Items #12 and #13: Field (49) and (50) Delivery Start Date and Delivery End Date:

In the same way as item #6, items #12 and #13 should be populated in the ISO 8601 standard, i.e. YYYY-MM-DD. There should be no representation of time (hours, minutes, seconds etc.) used; the fields are strictly date type fields.

Item #14: Progressive Number for equal trades on the same date:

For trades/contracts executed on the same day with exactly the same trade terms (i.e. items from 1 to 19) the progressive number will be used to differentiate each UTI that will be generated. This is a function of the UTI generator tool and does not need to be populated by the market participant.

It does not matter which trade obtains which progressive number for the UTI, as the UTI generator tool will increment the progressive number by one for each trade with the same terms.

Section (2) Relevant fields to be taken into account for the generation of the Contract ID for the reporting of transactions with Table 2 of the Annex of REMIT Implementing Regulation. Please see the TRUM for further details.

Table 2

#	Field No in TRUM	Field name  in the Table 2 Contract ID Generator	Value in the Table 2 Contract ID Generator (example)
1	1	Buyer's ACER code	C0643778W.EU
2	3	Seller's ACER code	C06AG978W.EU
3	13	Contract Type	FW
4	14	Commodity	EL
5	31	Settlement	P
6	12	Contract Date (without time)	2014-11-21
7	n/a	n/a	n/a
8	n/a	n/a	n/a
9	n/a	n/a	n/a
10	n/a	n/a	n/a
11	41	Delivery Point or zone	10YCB-EUROPEU--4
12	42	Delivery Start Date	2015-01-01
13	53	Delivery End Date	2015-01-31
14	n/a	Progressive Number (for equal contract on the same date)	1
15	n/a	Concatenated values	C0643778W.EUC06AG978W.EUFWE LP2014-11-2110YCB-EUROPEU-- 42015-01-012015-01-31
16	n/a	Hash of the concatenated values	qZ9uPVrjPK6Bzl2xNCUNkOn5rUXB9 svJdxMjcg3hY9oC
17	11	Contract ID	qZ9uPVrjPK6Bzl2xNCUNkOn5rUXB9 svJdxMjcg3hY9001

Items #1 & #2: Field (1) Buyer's ACER code and Field (3) Seller's ACER code:

The Agency would like to avoid any inconsistent interpretations or views which may arise from an individual market participants’ perspective in terms of who is a buyer or who is a seller.

Each contract has unambiguously defined a buyer (the one who accepts a commodity or an instrument) and a seller (the one who gives up a commodity or an instrument). Therefore field 1 always requires the buyer's ACER code whereas field 2 always requires the seller's ACER code irrespective of who (buyer or seller) is reporting. Please note that the code must be an ACER code and no other code (such as an EIC, LEI or BIC) is allowed.

Where a contract allows either party to buy or sell then the buyer should be defined as the market participant that is first alphabetically, with the other market participant being defined as the seller.

Any deviations from the above will result in the generation of different Contract IDs which would therefore be invalid.

Item #3: Field (13) Contract Type:

The range of accepted values for the Contract Type is available in the TRUM. However, the value “OT” (Other) should never be used and it is not allowed to be used in the UTI generator tool.

In addition, the Agency’s UTI algorithm always replaces the following contract types:

• If contract type is "SW" and Settlement method is "P" or "O", then its value is replaced with "FW”;
• If contract type is "SP" and Settlement method is "P" or "O", then its value is replaced with “FW”;
• If contract type is "SP" and Settlement method is set to "C", then its value is replaced with “SW”;
• If contract type is “OP_FW” or “OP_SW””, then its value is replaced with “OP”;
• Please note that “AU”, “CO”, “FU” or “OP_FU” are not allowed to be used in the UTI generator tool.

Item #4: Field (14) Commodity:

The range of accepted values for the Commodity is available in the TRUM.

Item #5: Field (31) Settlement:

The range of accepted values for the Settlement is available in the TRUM. However, if Settlement method is “O” (Optional for counterparty) then its values is replaced with "P” in the Concatenated value.

Item #6: Field (12) Contract date (without time):

This field should be populated in ISO 8601 standard, i.e. YYYY-MM-DD. There should be no representation of time (hours, minutes, seconds etc.) used; the field is strictly a date type field.

Items #7 to #10:

Not used in the UTI generation process for the REMIT Table 2 contracts.

Item #11: Field (41) Delivery Point or zone:

Only EIC codes published in the “List of Accepted EICs” in ANNEX VI to the TRUM must be used.

There is no automatic (built-in) normalization in the UTI generation.

This field should be populated with the EIC Y, EIC W or EIC Z for the delivery point or zone of the trade. In cases where there are more than one delivery points or zones relevant to the trade, the market participants should use the first EIC code in alphanumeric order (i.e. 0-9, A-Z) in the UTI generator tool.

Items #12 and #13: Field (42) and (43) Delivery Start Date and Delivery End Date:

IIn the same way as item #6, items #12 and #13 should be populated respecting the ISO 8601 standard, i.e. YYYY-MM-DD. There should be no representation of time (hours, minutes, seconds etc.) used; the fields are strictly date type fields.

Item #14: Progressive Number for equal contracts on the same date:

For contracts executed on the same day with exactly the same contract terms (i.e. items from 1 to 13) the progressive number will be used to differentiate each Contract ID that will be generated. This is a function of the UTI Generator tool and does not need to be populated by the market participant.

It does not matter which contract obtains which progressive number for the Contract ID, as the UTI generator tool will increment the progressive number by one for each contract with the same terms.

Section (3) Technical note on the BASE64SHA256 function

1. Transform the text to be hashed in a buffer of byte.
2. Apply the sha256 function (the sha256 function produces a buffer of 256 bits, normally every 8bits corresponds to 1 ASCII character, but if HEXADECIMAL code is used, 4 bits corresponds to a character).
3. Encode the result in BASE64 (in BASE64 every 6bit corresponds to a character so using 256/6 will result in 42 characters, with the remaining three characters being used to manage duplications).

The APIs used are the ones provided by .NET framework.

[Download PDF]

Version history

Version	Effective Date
ANNEX IV – Guidance on the Unique Transaction ID (UTI) 1.0	06 October 2015
ANNEX IV – Guidance on the Unique Transaction ID (UTI) 2.0	07 January 2019
ANNEX IV – Guidance on the Unique Transaction ID (UTI) 2.1	16 November 2022