slug: /docs/mydebit/overview/mydebit-iso8583-specifications

MyDebitMyDebit CnpMyDebit Iso8583 Specifications

MyDebit ISO8583 Specifications

What is ZMK?

ZMK is a Key Encryption Key (KEK) generated by member banks usually using three clear ZMK components.

What is it for?

The ZMK is used to encrypt and decrypt the Zone Authentication Key (ZAK) and Zone Pin Key (ZPK) during the key exchange messages.

How to configure ZMK?

The ZMK key (including its components) length supported by PayNet is 128-bit key (double length key) for 3DES encryption type.

For TR-31 Key Block, PayNet is supporting 192-bit (triple-length / 48-hexadecimal) ZMK component length for the 3DES encryption/decryption.

Member banks must key in all the components at PayNet HSM to generate the ZMK encrypted under PayNet Local Master Key (LMK).

This encrypted ZMK will be then stored in PayNet switch application and will be used to encrypt Zone PIN Key (ZPK) and Zone Authentication Key (ZAK) during key exchange process.

Introduction to ISO8583 TCP Message

The PayNet ISO Message

The PayNet ISO message is based on the ISO 8583:1987 published by International Organization for Standardization (ISO). It is a variable-length, variable-content message that can be configured differently, based on the type of message being sent.

Throughout this specification document, incoming refers to messages being received by PayNet and outgoing refers to messages being sent by PayNet.

PayNet ISO Message Components & Structure

The PayNet ISO message is made up of the following elements, structured as shown below. Some of these elements are mandatory, others are optional. Each is discussed in depth on the following pages.

PayNet ISO External Message Components

Component	Length	Required	Value
i. ISO Literal/Start-of-Header Indicator	3 bytes	Yes	Read Details
ii. PayNet Message Header	9 bytes	Yes	Read Details
iii. Message type identifier	4 bytes	Yes	Read Details
iv. Primary bitmap	16 bytes	Yes	Read Details
v. Secondary bitmap	16 bytes	Optional	Read Details
vi. Data elements	Variable length	N/A	Read Details

i. ISO Literal/Start-of-Header Indicator

PayNet uses, and requires, the literal ISO as its start-of-header indicator for messages. These three characters signal the start of the PayNet header.

For outbound messages, they are always present; for inbound messages, they are always required.

For inbound messages, the PayNet ISO Interface strips off any characters up to and including this start-of-header indicator and discards them.

ii. PayNet Message Header

The PayNet message header is required for all messages. It must immediately follow the ISO start-of-PayNet header indicator. The message header is nine positions in length and contains the following fields:

iii. Message Type Identifier

The PayNet message header is required for all messages. It must immediately follow the ISO start-of-PayNet header indicator. The message header is nine positions in length and contains the following fields:

iv. Primary Bit Map

The primary data element is a 16-bytes data element required in all messages. It represents 64 bits of data used to identify the present (denoted by 1 or bit on) or absence (denoted by 0 or bit off) of the first 64 data elements in the message.

Sixty-four bits are converted to and from 16 bytes of display data using hexadecimal (hex) equivalents:

Conversion Table

Bit Value	Hex Value	Bit Value	Hex Value
0000	0	1000	8
0001	1	1001	9
0010	2	1010	A
0011	3	1011	B
0100	4	1100	C
0101	5	1101	D
0110	6	1101	E
0111	7	1111	F

To convert 64 bits to 16 bytes, the 64 bits are first divided into 16 groups of four. Then, each group of four bits is assigned a hexadecimal equivalent according to the table shown above.

It is the hexadecimal equivalents that are carried in the data element of the PayNet ISO message.

The following is an illustration of how 64 bits are converted to 16 bytes for placement in the PayNet ISO message. Bits are numbered from left to right, starting with 1.

Bit	0010	0010	0001	1010	0100	0011	0000	0000	0000	0101	0010	0011	0110	1111	1011	1101
Hex	2	2	1	A	4	3	0	0	0	5	2	3	6	F	B	D

In the example, the data element would contain 221A430005236FBD.

Two data elements are used in the PayNet ISO message: the primary data element and the secondary data element. The primary data element controls the present or absence of data elements 1 through 64. The secondary data element controls the present or absent of data elements 65 through 128. The primary data element precedes the data elements in a message. The secondary data element is itself a data element (P-1) and its existence is controlled by the primary data element. When present, it immediately follows the primary data element.

vi. Data Elements

The PayNet ISO message allows for the transmission of the primary and secondary 128 data elements that are a part of the ISO 8583 standard. Not all of these data elements are used for processing by PayNet, however. In fact, many times only a small number are required. A primary advantage of the PayNet ISO message is that a data element need not be included in the message if it is not needed for processing.

The PayNet Interchange module has a set of defaults that it uses for determining which of the 128 data elements are to be included in each message. These defaults are established to provide the Interface module with the standard data elements it needs for processing transactions.

vii. End of Text (ETX)

End of Text (ETX) is an ASCII control character sent in Hexadecimal as “03” to indicate the end of message.

ETX is present in Network/ Key Management request messages (0800) initiated by PayNet to member bank. In case where an echo test message has been initiated by a member bank, then the ETX will be present in 0810 response message from PayNet to member bank. In the scenario where PayNet sends 0820/1 message to member bank, ETX will also be included in the message.

ETX is also included in 0500 Reconciliation Request message from PayNet to member bank.

In financial transaction messages, ETX is included in 0200 request message from PayNet to Issuer and 0210 response message from PayNet to Acquirer. ETX is also included in the 0420/1 reversal advice message and 0430 reversal acknowledgement message from PayNet to member bank. In Pre-Authorization, ETX is included in 0100 Pre-Authorization request message and 0120/1 (Sales Completion Request/ Repeat) from PayNet to Issuer. In Pre-Authorization response from PayNet to Acquirer, ETX is included in 0110 response message and 0130 (Sales Completion Acknowledgement) message.

ETX may or may not be present in the request or response messages from member bank to PayNet. However, if member bank include ETX in the incoming message to PayNet with value other than Hexadecimal “03”, it will be considered as part of the message data (ETX does not exist).

Message Flows

Network/Key Management Message Flows

Network management messages are used to manage the operational status of the communications lines between PayNet and the member bank. The PayNet ISO Interface supports the following types of network management messages:

• Logon messages
• Echo test messages
• Logoff messages
• Dynamic Key Management
• Cutover messages

This section describes the message flows that occur when logon, echo test, logoff, and cutover network management messages are sent. It also describes the message flows for new key message, which is used exclusively with dynamic key management (DKM).

i. Logon/Echo Test Initiated by PayNet

The diagram below illustrates the message flow between PayNet and the member bank for a logon or echo test message. The steps in the diagram are described below.

• 1
  To initially log on, PayNet sends a 0800 logon message to the member bank with an information code of 001. PayNet can also periodically send a 0800 message to the member bank with an information code of 301 to ensure the link is still up between PayNet and the member bank. When the information code is set to 301, this means that the 0800 message is an echo test message.
• 2
  The member bank responds with a 0810 message. The response code in the 0810 message indicates whether the member bank processed the logon successfully.

0800 Network / Key Management Request Message

The following table summarizes the PayNet ISO message element defaults established for Network or Key Management Request message. It is sent by PayNet to member bank or vice versa, depending on the value of the data element S-70.

Bit No	Data Element Name	Attrib		Remarks
---	Message Type	N 4	M	0800
---	Primary Bit Map	AN 16	M
P-1	Secondary Bit Map	AN 16	M
P-7	Transmission Date and Time	N 10	M	MMDDhhmmss
P-11	Systems Trace Audit Number	N 6	M	From 0500
P-15	Settlement Date	N 4	M	MMDD (Is used when S-70 is set to ‘201’ for cutover)
P-48	Additional Data	ANS 19	C	Is used when S-70 is set to ‘001’ for logon
P-53	Security Related Control Information	N 16	C	Is used when S-70 is set to ‘162’
S-70	Network Management Information Code	N 3	M	001 = Sign-on 002 = Sign-off 162 = New Key 201 = Cut-off 301 = Echo test
S-110	TR-31 Key Block	ANS 100	C	Must be present if TR-31 Key Block is supported.
S-120	PayNet Key Management	ANS 9	C	Must include in the message if S-70 set to ‘162’
S-123	PayNet Cryptographic Service Message (CSM) Information	ANS…153	C	Must include in the message if S-70 set to ‘162’. Must not be present if TR-31 Key Block is supported.

Logon Sample

ASCII value:

ISO02500006008008220000000010800040000000000000010050256570000020160111001112M000000003000000000000001

Breakdown of logon sample:

Value	Description	Length
ISO	ISO Literal/Start-of-Header Indicator	3 bytes
025000060	PayNet Message Header	9 bytes
0800	Message Type Identifier	4 bytes
8220000000010800	Primary Bitmap represented in Hex	16 bytes
0400000000000000	Secondary Bitmap represented in Hex	16 bytes
1005025657	Field P-7; Transmission Date and Time	10 bytes
0160111001112M00000	Field P-48; Additional Data — Network Management Data	19 bytes (includes a 3 bytes length indicator data)
0003000000000000	Field P-53; Security Related Control Information	16 bytes
001	Field S-70; Network Management Information Code	3 bytes

ii. Logoff Initiated by PayNet

The diagram below illustrates the message flow between PayNet and the member bank for a logoff message. The steps in the diagram are described below.

• 1
  PayNet sends a 0800 message to the member bank with an information code of 002. It also sets a timer and waits for a response from the member bank. If the member bank does not respond before the timer expires, PayNet sets another timer. If the member bank does not respond before the second timer expires, PayNet sends another logoff message. This step is repeated until PayNet receives a response to the 0800 message.
• 2
  The member bank responds with a 0810 message indicating that the logoff was successful. When PayNet receives the 0810 message, it deletes the timers set for the station named in the logoff message.

iii. Echo Test Initiated by Member Bank

The diagram below illustrates the message flow between PayNet and the member bank when the member bank initiates a logon or echo test message. The steps in the diagram are described below.

• 1
  The member bank can also periodically send an 0800 message to PayNet with an information code of 301 to ensure the link is still up between PayNet and the member bank. When the information code is set to 301, this means that the 0800 message is an echo test message.
• 2
  PayNet responds with a 0810 message.

Cryptographic Service Message

The ANSI X9.17 standard, Financial Institution Key Management (Wholesale), establishes standards for key management. This standard also defines the Cryptographic Service Message (CSM) used for moving key management data between processors when the keys are distributed automatically. CSM information is contained in the Cryptographic Service Message data element (S-123) of the ISO message and the Key Management data element (52) of the ANSI message. This is only applicable if member bank does not support TR-31 key block.

i. Key Distribution Environment

PayNet uses the point-to-point key distribution environment. In this environment, two parties share a key encryption key so that further data keys can be exchanged and one or both of the parties has the capability to generate or otherwise acquire keys.

ii. Message Classes

PayNet supports the following classes of CSMs used in point-to-point environments:

• Request Service Initiation Message (RSI)
• Key Service Message (KSM)
• Response Service Message (RSM)
• Error Service Message (ESM)

iii. Message Fields and Sub-fields

Each CSM class contains several fields, with many of the fields containing subfields. Some fields / subfields are mandatory while others are optional.

Because of this flexibility, each field begins with a unique 2- or 3-character identifier and ends with a blank. The CSM itself always begins with the literal CSM, and the message contents are always carried between a pair of parentheses.

The fields shown in the following table are the only ones that appear in the CSMs created by PayNet. There are five CSM formats because the ESM class can have two formats, depending on the type of error being reported. Each of the CSM formats is described in greater detail, following the table.

CSM Class	RSI	KSM	RSM	>ESM
				With Counts	Without Counts
CSM Fields	MCL	MCL	MCL	MCL	MCL
	RCV	RCV	RCV	RCV	RCV
	ORG	ORG	ORG	ORG	ORG
	SVR	KD		CTP	ERF
				CTR
				ERF

When the PayNet interface process receives CSMs generated by an external processor, it searches only for the fields shown in the preceding table. It is recommended, but not mandatory, that the fields in the message be kept in the order shown in the table.

vi. Message Formats

PayNet dynamic key management processing uses the CSM to move key information between the PayNet and the external processor in key management messages described earlier in this section. The following describes and presents examples of the PayNet supported CSM classes:

Key Service Message (KSM) — Used when a new key is passed between processors. An example of a CSM containing the KSM format is shown below:

An example of a CSM containing the KSM format

3DES

CSM(MCL/KSMØRCV/1234567890123456ØORG/1234567890123456ØKD/12345678901234567890123456789012ØCTP/12345678901234Ø)

DES CSM(MCL/KSMØRCV/1234567890123456ØORG/1234567890123456ØKD/1234567890123456ØCTP/12345678901234Ø)

The information in this example is actually a continuous line. It has been broken here due to space constraints. Each field in the message is preceded by one of the following identifiers. The blanks identified by the character Ø in the example are required in the message because they act as field terminators. The lengths given in the following field descriptions are for the data in the field, excluding field identifiers and trailing blanks.

An example of a continuous line

MCL/ = Message class (KSM)

Field Length: 3 alphabetical characters

RCV/ = Receiver of the message (FIID, refer to Appendix C)

Field Length: 4–16 alphanumeric characters

ORG/ = Originator of the message (FIID, refer to Appendix C)

Field Length: 4–16 alphanumeric characters

KD/ = New key value, generated by the security module for a new key request and taken from the database for a repeat key message

Field Length: 32 (3DES) or 16 (DES) hexadecimal characters

CTP/ = Hexadecimal key counter

Field Length: 1–14 hexadecimal characters

Response Service Message (RSM) — Used to respond to a KSM that is processed successfully. An example of a CSM containing the RSM format is shown below:

An example of a CSM containing the RSM format

CSM(MCL/RSMØRCV/1234567890123456ØORG/1234567890123456Ø)

Each field in the message is preceded by one of the following identifiers. The blanks identified by the character Ø in the example are required in the message because they act as field terminators. The lengths given in the following field descriptions are for the data in the field, excluding field identifiers and trailing blanks.

Error Service Message (ESM) — Used to respond to a Key Service Message (KSM) that cannot be processed successfully. The ESM can have two formats, depending on the type of error being reported. The two counter fields are only included in the message when the expected key count (CTP field) and the key count received from the message originator (CTR field) do not match. The error code (ERF field) in the examples below can contain only alphabetical characters. Numbers are used to demonstrate field length.

An example of a Error Service Message (ESM)

MCL/ = Message class (RSM)

Field Length: 3 alphabetical characters

RCV/ = Receiver of the message (FIID, refer to Appendix C)

Field Length: 4–16 alphanumeric characters

ORG/ = Originator of the message (FIID, refer to Appendix C)

Field Length: 4–16 alphanumeric characters

An example of a CSM containing the ESM format with the key counters is shown below:

An example of a CSM containing the ESM format

CSM(MCL/ESMØRCV/1234567890123456ØORG/1234567890123456ØCTP/12345678901234ØCTR/12345678901234ØERF/1234567890123456Ø)

An example of a CSM containing the ESM format without the key counters is shown below:

An example of a CSM containing the ESM format without the key counters

CSM(MCL/ESMØRCV/1234567890123456ØORG/1234567890123456ØERF/1234567890123456Ø)

The information in each of these examples is actually a continuous line. It has been broken here due to space constraints. Each field in the messages is preceded by one of the following identifiers. The blanks identified by the character Ø in the example are required in the message because they act as field terminators. The lengths given in the following field descriptions are for the data in the field, excluding field identifiers and trailing blanks.

tip

MCL/ = Message class (ESM)

Field Length: 3 alphabetical characters

RCV/ = Receiver of the message (FIID, refer to Appendix C)

Field Length: 4–16 alphanumeric characters

ORG/ = Originator of the message (FIID, refer to Appendix C)

Field Length: 4–16 alphanumeric characters

CTP/ = Hexadecimal key count expected by the receiver of the KSM. This identifier and field are only included in the message when error code P is returned.

Field Length: 1–14 hexadecimal characters

CTR/ = Hexadecimal key count originally sent in the KSM by the message originator. This identifier and field are only included in the message when error code P is returned. Field Length: 1–14 hexadecimal characters

ERF/ = The following codes identify the errors that were detected during processing.

C = Cannot process (general error)

F = Format error

H = Invalid receiver ID or originator ID

P = The value in the CTP field of the KSM does not match the expected count

Field Length: 1-16 alphabetical characters

The information in each of these examples is actually a continuous line. It has been broken here due to space constraints. Each field in the messages is preceded by one of the following identifiers. The blanks identified by the character Ø in the example are required in the message because they act as field terminators. The lengths given in the following field descriptions are for the data in the field, excluding field identifiers and trailing blanks.

vii. Message Length

The use of multiple CSM formats makes the CSM a variable-length element in the ISO message. The CSM can also be a fixed-length element in the ISO message, and is always a fixed-length element in the ANSI message.

PayNet MyDebit scheme ONLY support CSM with variable-length element in the ISO message.

Message Length

When the CSM is used as a variable-length element, the length of each field in the CSM is determined by the data it carries. The message format fields descriptions presented earlier in this section include the range of possible lengths for each field.

All fields are required except for the key count fields (CTP and CTR) in the ESM. The key count fields are conditional in the ESM, depending on whether the error code field (ERF) contains a P (counts do not match). Neither key count field is included when the error code is a value other than P. Data element S-123 can have the following lengths (excluding the 3-position field length indicator), depending on the CSM format it contains.

CSM Format	KSM	RSM	>ESM
			With Counts	Without Counts
Minimum Length	57	31	49	37
Minimum Length	57	31	49	37

Example

The following examples show an RSM when the receiver and originator are less than the maximum length of 16 alphanumeric characters. The first example illustrates a variable-length format and the second example illustrates a fixed-length format. The variable-length RSM shown has a length of 36 characters while the fixed-length RSM shown maintains its length of 55 characters because each field is padded with blanks. Blanks are identified by the character Ø in the examples.

An example of a RSM when the receiver and originator are less than the maximum length of 16 alphanumeric characters

CSM(MCL/RSMØRCV/ABC123ØORG/DEFG456Ø)

CSM(MCL/RSMØRCV/ABC123ØØØØØØØØØØØORG/DEFG456ØØØØØØØØØØ)

Key Management Message Flows

Key management messages make up a subset of network management messages. These messages are sent as 0800 messages and require 0810 messages in response. There are four key management messages available by ISO but PayNet only support New Key management message with member bank.

The new key messages can be generated automatically, as the result of a defined threshold being surpassed, or manually, when an operator issues a command from the system console.

In addition, key management information is passed in data elements S-70 (Network Management Information Code) and S-123 (Cryptographic Service Message). For more information on these two data elements, Refer Section 5

i. New Key

A request for a new PIN key from the PayNet ISO Interface to a member bank can be initiated by entering a key change command from the system console or it can be done automatically when threshold parameters configured for Dynamic Key Management (DKM) are surpassed. The member bank shares control of DKM processing with the PayNet ISO Interface. However, its depends on member bank/co-network on how they want to control/manage their system. All member banks currently change key minimum once a day after logon. PayNet, the master process is responsible for new key generation. This message flow is used only with DKM.

ii. New Key Message Flow

The diagram below illustrates the message flow between the PayNet and the member bank when the PayNet ISO Interface sends a new key message. The new key message can be sent manually using text commands or programmatically when the threshold for a defined working key has been surpassed. In this scenario, the PayNet ISO Interface is responsible for generating the key being sent. The steps corresponding to the diagram are also described below.

• 1
  The PayNet ISO Interface creates a New Key message and sends it to the member bank. To do this, the PayNet ISO Interface performs as follows:

  a. Generates the new key and check digits.

  b. If the member bank does not support TR-31 key block, the interface formats a Key Service Message (KSM) containing the new key and the check digits, otherwise this step is bypassed.

  c. Sends an 0800 message to the member bank with the network management information code set to 162. If the member bank does not support TR-31 key block, the message includes the Cryptographic Service Message data element (S-123) containing the KSM, otherwise 0800 message will include S-110 instead, that will be used to distribute the TR-31 key block.

  d. Sets an internal flag indicating that a key exchange is in progress for the type of key being sent.

  e. Starts a Network Management Message timer for the message. If this timer expires before an 0810 response is received from the member bank, the PayNet ISO Interface starts an Extended Network Management Message timer for the message. If the Extended Network Management Message timer expires, the PayNet ISO Interface resends the New Key message.
• 2
  The member bank receives the New Key message, processes it, and returns an 0810 response message with a network management information code of 162 to the PayNet ISO Interface. If the member bank does not support TR-31 key block, the message includes the Cryptographic Service Message data element (S-123) containing either a Response Service Message (RSM) or an Error Service Message (ESM) otherwise field S-123 is omitted from the 0810 response message.

3

1. Verifies that the original 0800 message did not time out.
   1. If the 0800 message timed out before the 0810 response was received, the PayNet ISO Interface drops the message, and no further steps are performed.
   2. If the 0800 message has not timed out, processing continues with the next step.
2. Clears the internal flag indicating that a key exchange is in progress.
3. Continues processing depending on the response code sent in the 0810 response message.
   1. If the transaction was denied, the PayNet ISO Interface parses the Cryptographic Service Message data element (S-123) to determine why the new key was denied. In this case, the Cryptographic Service Message data element contains an Error Service Message (ESM).
      • If the ESM indicates the message was denied because PayNet’s key counter does not match the key counter maintained by the member bank, the PayNet ISO Interface resets its key counter in the KEYF to the value sent by the member bank. The PayNet ISO Interface then resends the new key. Processing returns to step 1.
      • If the member bank does not support TR-31 and if the ESM indicates that any other error occurred, the PayNet ISO Interface sends a message indicating the error to the network logging facility and drops the 0810 response.
   2. If the transaction was approved, the PayNet ISO Interface updates the KEYF with the new key, check digit, and counter information. The PayNet ISO Interface also reinitializes its internal key change threshold counters and timers

Key Exchange

ASCII value:

ISO02500006008008220000000000800040000000000012010050325340000030003000000000000162006e20d00090CSM(MCL/KSM RCV/123456 ORG/paynet KD/5d337ba4889212ac2f61fbecd69f5ea6 CTP/00000000000009 )

Breakdown of Key Exchange message sample:

Value	Description	Length
ISO	ISO Literal/Start-of-Header Indicator	3 bytes
025000060	PayNet Message Header	9 bytes
0800	Message Type Identifier	4 bytes
8220000000000800	Primary Bitmap represented in Hex	16 bytes
0400000000000120	Secondary Bitmap represented in Hex	16 bytes
1005032534	Field P-7; Transmission Date and Time	10 bytes
000003	Field P-11; Systems Trace Audit Number	6 bytes
0003000000000000	Field P-53; Security Related Control Information	16 bytes
162	Field S-70; Network Management Information Code	3 bytes
006e20d00	S-120; Key Management	9 bytes (includes a 3 bytes length indicator data)
CSM(MCL/KSM RCV/123456 ORG/paynet KD/5d337ba4889212ac2f61fbecd69f5ea6 CTP/00000000000009 )	S-123; Cryptographic Service Message	Variable length data (Includes a 3 bytes length indicator data)

Data Elements

This section contains descriptions for the data elements of the PayNet ISO Message. The data elements controlled by the primary data element are described first, followed by descriptions of the data elements controlled by the secondary data element.

Documentation Template

The data elements used in the PayNet ISO Message are described in detail in this section. A standard format has been used for describing these data elements.

The standard format is as follows:

• Format: States the attributes for the data element. The values used to represent the attributes are based on the ISO/DIS 8583 standards:
• For fixed-length data elements, the above characters are followed by the number of characters in the data element (e.g., N 10 indicates that the data element is a fixed-length, 10-position, numeric data element).
• For variable-length data elements, the above characters are followed by two dots and the maximum number of characters that can be carried in the data element (e.g., A ..21 indicates that the data element is a variable-length, alphabetic data element, which can be from zero to 21 characters in length).
• X+ is used with some amounts to indicate that they must be preceded by a capital C if the amount is a credit or a capital D if the amount is a debit. This adds one to the given length of the data element.
• Date and time formats are shown using the following values:

Standard Format

ASCII value:

A = Alphabetic characters

N = Numeric characters

S = Special characters

AN = Alphabetic and numeric characters

AS = Alphabetic and special characters

NS = Numeric and special characters

ANS = Alphabetic, numeric, and special characters

YY = Year

MM = Month

DD = Day

hh = Hour

mm = Minute

ss = Second

B = Binary

Throughout this section, A, N and “..” refer to data element format of Alphanumeric, Numeric and Variable data-length respectively. For the Variable data-length data element, data length must be specified in 2 or 3 bytes of the data element.

P-1

P-1	Secondary Bit Map	Format: AN 16
This data element identifies the present or absence of data elements 65 through 128 in the PayNet ISO Message. It functions the same as the Primary Bit Map, except that the Primary Bit Map identifies the present or absence of data elements 1 through 64 and the Secondary Bit Map identifies the present or absence of data elements 65 through 128. The Secondary Bit Map is required if any of data elements 65 through 128 are included in the message. Otherwise, it is not used. The present or absence of the Secondary Bit Map is identified by bit position 1 in the Primary Bit Map. If the Secondary Bit Map is absent from the Primary Bit Map, this means that data elements 65 through 128 cannot be included in the message. This data element is set by the originator of the message.

P-7

P-7	Transmission Date and Time	Format: N 10 (MMDDhhmmss)
The time the message entered into the interchange system. It is reset for each outgoing message and is expressed in local time. This data element is filled in by the Acquirer. Transmission Date and Time is mandatory for all message types. On incoming PayNet messages, the Transmission Date and Time is not processed. This data element may be set to member banks current time for incoming messages sent by them. On outgoing PayNet messages, the Transmission Date and Time is set to the current local time.

P-11 Systems Trace Audit Number

P-11	Systems Trace Audit Number	Format: N 6
A number used for matching responses to messages. This number must be set by a message sender and echoed by a message receiver. It is used for matching responses to original messages and is not intended to remain the same throughout the life of a transaction. This data element is filled in by the Acquirer. Systems Trace Audit Number is mandatory for all messages to and from PayNet. In the 0420 reversal message generated by Acquirer, the value for this field must be the same as the value in the original 0200 request message from Acquirer. For 0420 reversal generated by PayNet, the trace number will be different from original 0200 message to Issuer. In network management messages, the Systems Trace Audit Number is used to match the network management request with its response. PayNet generates the number on outgoing 0800 messages and expects it to be returned in the corresponding 0810 messages. On outgoing 0810 messages, PayNet echoes the number sent in the corresponding 0800 messages. In reconciliation messages, the Systems Trace Audit Number is used to match the reconciliation request with its response. PayNet generates the number on outgoing 0500 messages and expects it to be returned in the corresponding 0510 messages. On outgoing 0510 messages, PayNet echoes the number sent in the corresponding 0500 messages. This applies to all 0500-series request and response messages.

P-15 Settlement Date

P-15	Settlement Date	Format: N 4 (MMDD)
The date the transaction will be settled by the member bank. Settlement Date is used by PayNet to hold the Acquirer’s settlement date. Settlement Date is populated by PayNet for 0200 message type to Issuer. Issuer shall populate the Settlement Date in 0110 and 0210 response message. In reconciliation messages, Settlement Date is the date to which the totals figures apply. Settlement Date is mandatory for all reconciliation messages. In network management messages, Settlement Date is mandatory for 0820 and 0830 messages and conditional for 0800 and 0810 messages. When Network Management Code (S-70) is set to 201 for cutover, the date in Settlement Date is the business date for the processing day just ended. PayNet checks 0830 messages with data element S-70 set to 201. If the date is not equal to the previous date for PayNet, the message will be dropped. PayNet does not check this for 0820 messages. Settlement Date is mandatory for 0210, 0420 and 0421 messages. If Acquirer timeout with late 0110/ 0210 response message from PayNet, the value for this field in the 0420 reversal message from Acquirer to PayNet will contain zeroes.

P-48 Additional Data — Retailer Data

P-48	Additional Data — Retailer Data	Format: ANS 30 (includes a 3-position length indicator data element
Carries the information required to identify the retailer involved in the transaction. This data element is set by the Acquirer. It is mandatory for all authorization, financial transaction, reversal, and reconciliation control messages, with the exception of 0110, 0130 and 0430 messages. The structure of P-48 is provided below. Included for each field is the field’s position in the element, its field length, and a description of its contents.
Position	Type	Length	Description
01 - 03	ANS	3	Field length indicator This field must be set to 027.
04 - 22	ANS	19	Retailer ID The name of the retailer initiating the transaction. It is assigned by the Acquirer bank. The name used must not exceed 19 characters. If name of the retailer exceeds 19 characters, the name must be abbreviated in a comprehensive and meaningful manner.
23 - 26	ANS	4	Retailer Group The retailer group to which the retailer initiating the transaction belongs. This field is for each member bank’s internal tracking purposes. The group name must not exceed 4 characters. This field is set to blank, if member bank does not use the retailer group.
27 - 30	ANS	4	Retailer Region The retailer region to which the retailer initiating the transaction belongs. This field is for each member bank’s internal tracking purposes. The region name must not exceed 4 characters. This field is set to blank, if member bank does not use the region group.
For the 0420 reversal message type due to late response from Issuer, PayNet will carries this data element but without the data. In this condition, this data element will appear as “000”.

P-48 Additional Data — CNP Data

P-48	Additional Data — Retailer Data	Format: ANSB 97 (includes a 3-position length indicator data element)
This field carries the authentication data for Card Not Present transaction derived by Payment Gateway/ Payment Processer (PSP) . This data element is set by the Acquirer. It is mandatory for all authorization, financial transaction, reversal, and reconciliation control messages, with the exception of 0110, 0130, 0210 and 0430 messages. Acquirer to ensure that the value of this field for 0120 Sales Completion message must be the same as the 0100 Pre-Authorization request message. In the 0420 reversal message from Acquirer, the value of this field must be the same as per the original 0200 Purchase and Cancellation for Purchase request message. As for Issuer, the value of this field for 0120 Sales Completion & 0420 reversal message will be the same as the 0100 Pre-Authorization/ 0200 Purchase & Cancellation for Purchase request message except for OBS Indicator sub-field. Please refer to the special note indicated in the table below. The structure of P-48 is provided below. Included for each field is the field’s position in the element, its field length, and a description of its contents.
Position	Type	Length	Description
01 - 03	ANS	3	Field length indicator This field must be set to 0.
04 - 22	ANS	19	Retailer ID The name of the retailer initiating the transaction. It is assigned by the Acquirer bank. The name used must not exceed 19 characters. If name of the retailer exceeds 19 characters, the name must be abbreviated in a comprehensive and meaningful manner.
23 - 30	ANS	8	Reserved for future use The value of this sub-field is spaces.
31 - 50	Binary	20	DS Transaction ID If the transaction is Customer Initiated Transaction (CIT), DS Transaction ID is assigned by PayNet DS. If the transaction is Merchant Initiated transaction (MIT), the value of this sub-field would be the DS Transaction ID of the first CIT transaction The Acquirer Host will need to construct the DS Transaction ID in the format of binary prior transmitting to MyDebit Switch. Following sample DS Transaction ID received by Acquirer Host from 3DS Server: PN0000004317fdc3ad2454438000000000000891 Removed the “PN000000”: 4317fdc3ad2454438000000000000891 ACS need to change the DS-TRAN-ID to uppercase. Add trailing zeros of 4 bytes to make it total 20 bytes; the result would be: 4317FDC3AD245443800000000000089100000000 Convert to binary and include as part of P-48 Note: Value for this field will be initialized to zeroes for ECI17.
51	Binary	1	Reserved for future use Electronic Commerce Indicator. Valid value: 15: Both cardholder and card issuing bank are 3D enabled. 3D card authentication is successful. 16: Either cardholder or card issuing bank is not 3D enrolled. 3D card authentication is unsuccessful. 17: Authentication is unsuccessful or not attempted. ECI Value Hexadecimal Binary 15 15 0001 0101 16 16 0001 0110 17 17 0001 0111 Note: Acquirer may need to convert ECI value to Binary before populating it in this sub-field Issuer to convert ECI value from Binary if required In the Cancellation of Purchase transaction, the ECI will always follow the original Purchase transaction’s ECI.
52 - 71	Binary	20	Authentication Value Data: Value for this field will be initialized to zeroes for ECI17. Data Description Length 3DS Auth Result Code Issuer ACS authentication decision. Note:Leading zero padding is required in first unused half-byte. Valid value: 1: Authentication Successful. 7: Attempted Authentication response by the Issuer’s attempts ACS for a non-participating cardholder or by the PayNet Attempts service for non-participating Issuer 8: The attempted authentication response was generated by PayNet Attempts Service because the Issuer ACS was unavailable 1 Second Factor Auth Code Additional authentication method used by the Issuer ACS. Valid value: 01: Challenge flow using Static Password 02: Challenge flow using OTP via SMS 03: Challenge flow using OTP via APP 04: Challenge flow using OTP via any other method 05: Challenge flow using Knowledge-Based Authentication 06: Challenge flow using OOB with Biometric 07: Challenge flow using OOB with APP login 08: Challenge flow using OOB with any other method 09: Challenge flow using any other method 10: Frictionless flow with RBA 11: Attempts Server responding 1 PIAV Key Indicator PIAV key set used to calculate the PIAV value. Valid value: 01: PIAV Key Set 1 02: PIAV Key Set 2 10: PayNet Attempts Service Key Set 1 11: PayNet Attempts Service Key Set 2 Note: Leading zero padding is required in first unused half-byte. The value of this sub-field for Sales Completion and Cancellation of Purchase must be set to spaces. 4 PIAV Value PayNet Issuer Authentication Value generated by the ACS in coordination of the issuer using a key determined by the issuer and ACS when the issuer is self-validating PIAV value. Note: The value of this sub-field for Sales Completion and Cancellation of Purchase must be set to spaces. If under Attempts scenario i.e. ECI 16, PIAV will be defaulted to all zeros by DS. If under Not Authenticated scenario i.e. ECI 17, PIAV will be defaulted to all zeros by 3DS Server / Acquirer 4 PayNet OBS PAV PayNet portion of the PAV values for the purpose of OBS PAV validation. Will be validated by MyDebit Switch if Issuer opt for OBS. Else this value will be pass through to Issuer. Note: PayNet will validate this value for 0100 and 0200 request messages if the ECI value is 15 or 16 and the Issuer subscribe to OBS. Defaulted to zeros under ECI = 17. 11 PAV Key Indicator PAV key set used to calculate the PAV value. Valid value: 01: PAV Key Set 1 02: PAV Key Set 2 Note: Leading zero padding is required in first unused half-byte. Defaulted to zeros under ECI = 17. 1 Device Channel Supported value include: 01: APP—App-based Authentication 02: BRW—Browser-based Authentication 03: 3RI—Deviceless Payment Authentication 1
72 - 74	AN	3	On Behalf Service (OBS) Indicator (From Acquirer to PayNet): Data Description Length OB Service Acquirer to populate spaces regardless of ECI value. Note: In the 0420 message from Acquirer, the value of this subfield should be the same as per the original request message i.e. 0100/ 0200 message 2 OB Result Acquirer to populate spaces regardless of ECI value. Note: In the 0420 message from Acquirer, the value of this subfield should be the same as per the original request message i.e. 0100/ 0200 message. 1 On Behalf Service (OBS) Indicator (From PayNet to Issuer): Data Description Length OB Service Valid value: 05: Issuer subscribe to the OBS to validate the PAV 00: If Issuer do not subscribe to OBS Note: The OB Service value would be initialized to a space for the following: Transaction with ECI17 0120 Sales Completion (for all ECI values) 0420 messages (for all ECI values) Cancellation of Purchase (for all ECI values) 2 OB Result Valid value: I: Invalid PAV U: IUnable to Proces V: Valid PAV O: If Issuer do not subscribe to OBS Note: The OB Result value would be initialized to a space for the following: Transaction with ECI17 0120 Sales Completion (for all ECI values). 0420 messages (for all ECI values) Cancellation of Purchase (for all ECI values) PayNet will forward the OB result regardless of the outcome of validation. Issuer should consider the OB Result when authorizing the transaction regardless of the OB Indicator when the ECI is 16. 2
75	ANS	1	Payment IndicatorValid value: R: Recurring transaction This value indicates that the cardholder and merchant have agreed to periodic billing for goods and services. U: Unscheduled transaction This value indicates that cardholder and merchant have agreed to a periodic billing for goods and services. Space: If Payment Indicator not ‘R’ or ‘U’.
76 - 87	ANS	12	Original Purchase/ Sales Completion Retrieval Reference Number (P-37) This sub-field carry the Retrieval Reference Number (P-37) of the first CIT transaction. This sub-field contain spaces if Payment Indicator not ‘R’ or ‘U’.
88 - 93	ANS	6	Original Authorization Identification Response (P-38) This sub-field carry the Authorization Identification Response (P-38) of the first CIT transaction. This sub-field contain spaces if Payment Indicator not ‘R’ or ‘U’.
94 - 97	N	4	Original Authorization Identification Response (P-13) This sub-field carry the Transaction Date (P-13) of the first CIT transaction. This sub-field will be initialized to zeroes if Payment Indicator not ‘R’ or ‘U’.

Please refer to the notes on P-25 for the value of Payment Indicator, Original Retrieval Reference Number, Original Authorization Identification Response and Original Transaction Date to be populated in the sub-field position 31-50 and 75-97.

For the 0420 reversal message type due to late response from Issuer, PayNet will carries this data element but without the data. In this condition, this data element will appear as “000”.

Refer below for action required to be done by Issuer Bank based on ECI:

ECI Value	Issuer Subscribe to OBS (Yes/ No)	Action by Issuer Bank
15	Yes	Bank to validate the OB Result and proceed with authorization process
	No	Bank to validate the OB Result and proceed with authorization process
16	Yes	Bank to validate the OB Result and proceed with authorization process Note: For ECI 16, by default PayNet will validate PAV regardless if Issuer subscribe or do not subscribe to OBS
	No
15	Yes	Bank to proceed with authorization process
	No

P-48 Additional Data — Transit Program Data

P-48	Additional Data — Transit Program Data	Format: ANS 79 (includes a 3-position length indicator data element)
Carries the information required to identify the retailer involved in the transaction. This data element is set by the Acquirer. This field only applicable for 0200 CNP Authorization Request Message (Adjustment) and 0420 CNP Reversal Advice Message (Adjustment). The structure of P-48 is provided as below. Included for each field is the field’s position in the element, its field length, and a description of its contents.
Position	Type	Length	Description
01 - 03	ANS	3	Field length indicator This field must be set to 076.
04 - 22	ANS	19	Retailer ID The name of the transport service provider initiating the transaction. It is assigned by the Acquirer bank. The name used must not exceed 19 characters. If name of the retailer exceeds 19 characters, the name must be abbreviated in a comprehensive and meaningful manner.
23 - 28	ANS	6	Reserved for future use The value of this sub-field is spaces.
29 - 30	ANS	2	Transit Transaction Type Indicator 07 – Adjustment Debit (Special for Debt Recovery) 08 – Adjustment Debit (General) 09 – Adjustment Credit (General)
31 - 32	ANS	2	Transportation Mode Indicator 01 – Bus 03 – LRT/MRT/Monorail 05 – Komuter Train 07 – Toll 08 – Parking
33 - 57	ANS	25	Short URL for transaction details Example : https:\\bit.ly\XcvBNFmkBN
58 - 69	ANS	12	Original Purchase/ Sales Completion/ Pre-Authorization Retrieval Reference Number (P-37) For Adjustment Debit and Credit, Acquirer/ Issuer to refer to the Retrieval Reference Number (P-37) of the Purchase/ Sales Completion that need Adjustment. For Adjustment Debit (Special for Debt Recovery), Acquirer/ Issuer to refer to the Retrieval Reference Number (P-37) of the declined Purchase/ Pre-Authorization. Example: Purchase/ Pre-Authorization declined due to insufficient fund/ timeout/ contactless limit reached/ daily limit reached or any other declined reason which the card number and account are still valid and active.
70 - 75	ANS	6	Original Purchase/ Sales Completion/ Pre-Authorization Authorization Identification Response (P-38) For Adjustment Debit and Credit, Acquirer/ Issuer to refer to the Authorization Identification Response (P-38) of the Purchase/ Sales Completion that need Adjustment. For Adjustment Debit (Special for Debt Recovery), Acquirer/ Issuer to refer to the Authorization Identification Response (P-38) of the declined Purchase/ Pre-Authorization. Example: Purchase/ Pre-Authorization declined due to insufficient fund/ timeout/ contactless limit reached/ daily limit reached or any other declined reason which the card number and account are still valid and active.
76 - 79	ANS	4	Original Purchase/ Sales Completion/ Pre-Authorization Transaction Date (P-13) For Adjustment Debit and Credit, Acquirer/ Issuer to refer to the Transaction Date (P-13) of the Purchase/ Sales Completion that need Adjustment. For Adjustment Debit (Special for Debt Recovery), Acquirer/ Issuer to refer to the Transaction Date (P-13) of the declined Purchase/ Pre-Authorization. Example: Purchase/ Pre-Authorization declined due to insufficient fund/ timeout/ contactless limit reached/ daily limit reached or any other declined reason which the card number and account are still valid and active.
For the 0420 reversal message type due to late response from Issuer, PayNet will carry this data element but without the data. In this condition, this data element will appear as “000”.

P-48 Additional Data — Network Management Data

P-48	Additional Data — Network Management Data	Format: ANS 19 (includes a 3-position length indicator data element)
Carries information used by PayNet for network management messages. It is used for logons to the member bank. The information passed in this element determines the configuration processing options that each network is using. This information is vital and must be shared between the networks in order to correctly process transactions. This data element is set by PayNet. This data element is conditional for 0800 and 0810 messages. This data element is only sent when this is a logon request or response. A network management message for a logon is identified by a Network Management Code (S-70) of 001. The structure of P-48 is provided below. Included for each field is the field’s position in the element, its field length, and a description of its contents.
Position	Length	Description
01 - 03	3	Field length indicator This field must be set to 016.
04 - 05	2	Version Number The software version number of the PayNet ISO Interface. This field must be set to 01.
06	1	Acknowledgment to Switch Specifies whether PayNet sends text-level acknowledgments to the member bank. Valid values are: 1 = Yes, PayNet sends text-level acknowledgments to the member bank 0 = No, PayNet does not send text-level acknowledgments to the member bank The value of this field must be set to 1.
07	1	Acknowledgment from Switch Specifies whether PayNet expects text-level acknowledgments from the member bank. Valid values are: 1 = Yes, PayNet expects text-level acknowledgments from the member bank 0 = No, PayNet does not expect text-level acknowledgments from the member bank The value of this field must be set to 1.
08	1	Acquirer Stand In Authorization Specifies whether PayNet, when acting as the Acquirer, can stand in for the member bank. Valid values are: 1 = Yes, PayNet can stand in for the member bank 0 = No, PayNet cannot stand in for the member bank The value of this field must be set to 0.
09	1	Issuer Stand In Authorization Specifies whether the member bank, when acting as the Acquirer, can stand in for PayNet, when PayNet is acting as the Issuer. Valid values are: 1 = Yes, the member bank can stand in for PayNet 0 = No, the member bank cannot stand in for PayNet The value of this field must be set to 0.
10	1	Cutover Status The type of settlement logic configured for PayNet. Valid values are: 0 = PayNet and the member bank are equal settlement partners 1 = PayNet is the master settlement partner 2 = PayNet is the slave settlement partner If PayNet and the member bank are equal partners, each partner is responsible for its own cutover and each must send totals to the other partner at settlement. If PayNet is the master partner, PayNet controls when cutover should occur and is responsible for sending totals for settlement. If PayNet is the slave partner, the member bank controls when cutover should occur and is responsible for sending totals for settlement. The value of this field must be set to 1.
11	1	Encryption Type The type of PIN encryption configured for PayNet. The value of this field must be set to 1.
12	1	Number of Keys Indicates whether the inbound and outbound keys for a specific PayNet ISO Interface are combined or separate. Valid values are: 1 = Combined keys (inbound and outbound keys are equal) blank, 0, or 2 = Separate keys The value of this field must be set to 1.
13	1	Key Length Indicates whether single- or double-length Key Exchange Keys (KEKs) are used with this member bank. The value in this field is used when PIN and MAC keys are exchanged using dynamic key management. The PIN KEK and the MAC KEK must be the same length. Valid values are: 0, 1 = Single-Length Key Exchange Keys (KEKs) 2 = Double-Length KEKs The value of this field must be set to 0 or 1 for DES. For 3DES, the value must be set to 2.
14	1	Key Processing Type A code identifying the type of dynamic key management processing this PayNet ISO Interface can perform. Valid values are: 0, N = None M = Master S = Slave C = Member bank The value of this field must be set to M.
15	1	MAC Type Indicates the level of MAC support for this PayNet ISO Interface. Valid values are: 0 = No MAC support 1 = Hardware MAC support 2 = Software MAC support The value of this field must be set to 0.
16	1	Key Processing Type Indicates character set in which MAC data is formatted. Valid values are: 0 = ACSII 1 = EBCDIC The value of this field must be set to 0
17 - 19	1	Filler Reserved for future use.

P-53 Security Related Control Information

P-53	Security Related Control Information	Format: N 16
Security Related Control Information contains PayNet dynamic key management data. It is conditional for network management messages. The structure of P-53 is provided below. Included for each field is the field’s position in the element, its field length, and a description of its contents.
Position	Length	Description
01 - 02	2	Key Type A flag identifying the type of key being exchanged. Valid values are: 00 = PIN key 01 = MAC key
03 - 04	2	Key Direction A flag indicating the direction of the key being Exchanged. Valid values are: 01 = Outbound key only 02 = Inbound key only 03 = Both incoming and outgoing keys The value must be 03.1.
05 - 16	2	Reserved for future use The value of this sub-field is to be defaulted to zeros.

S-70 Network Management Information Code

S-70	Network Management Information Code	Format: N 3
A code used to manage the on-line processing status between PayNet and a member bank. It identifies the purpose of a network management request message. This data element is set by PayNet or member banks. The following network management information codes are supported by the PayNet ISO Interface:
001	Logon
002	Logoff
201	Cutover
301	Echo-test
162	New key
Network Management Information Codes 161, 162, 163, and 164 are used only for dynamic key management messages. The Network Management Information Code is mandatory for 0800, 0810, 0820, 0821 and 0830 messages.

S-110 TR-31 Key Block Data

S-110	TR-31 Key Block Data	Format: ANS ...100 (includes a 3-position data element length indicator)
A code used to manage the on-line processing status between PayNet and a member bank. It identifies the purpose of a network management request message. This data element is set by PayNet or member banks. The following network management information codes are supported by the PayNet ISO Interface:
Position	Length	Description
001 - 003	3	Field Length Indicator This data element must contain the length of the TR-31 Key Block.
004 - 103	100	TR-31 Key Block This field contains the generated PIN or MAC Working key in TR-31 Key Block format.
Below are the examples of TR-31 Key Block Values: PIN Working key in TR-31 Key Block Format B0096P0TB00E00005450948FD298FE32E418C3F0574CEE4FE3388FDFD722863C43CC24414025440C807AF25ABB07AAF3 MAC Working key in TR-31 Key Block Format B0096M1TC00E00007F7D1DA76232772EA0CD375E7209B382AF9C953351A918DEFE5DCD89F4B32A7A75921604C0A74E2B The structure of TR-31 Key Block

Header
Field Name	Format	Description
Key Block Version	AN 1	Field Length Indicator Identifies the version of the key block, which defines the method by which it is cryptographically protected and the content and layout of the block: ‘A’ – Key block protected using the Key Variant Binding Method 2005 Edition ‘B’ – Key block protected using the Key Derivation Binding Method 2010 Edition ‘C’ – Key block protected using the Key Variant Binding Method 2010 Edition Valid Value: ‘B’
Key Block Length	N 4	Field Length Indicator ASCII numeric digits providing key block length after encoding. Length includes the entire block (Header + Encrypted Key Data + MAC) in decimal.
Key Usage	AN 2	Field Length Indicator Provides information about the intended function of the protected key/sensitive data. ‘D0’ - Data Encryption using ECB, CBC, CFB, OFB, CCM, or CTR ‘M0’ - ISO 16609 MAC algorithm 1 (using TDEA) ‘M1’ - ISO 9797-1 MAC Algorithm 1 ‘M2’ - ISO 9797-1 MAC Algorithm 2 ‘M3’ - ISO 9797-1 MAC Algorithm 3 ‘M4’ - ISO 9797-1 MAC Algorithm 4 ‘M5’ - ISO 9797-1 MAC Algorithm 5 ‘P0’ - PIN Encryption Valid Values: ‘P0’ = Used for New PIN Working Key ‘M1’ = Used for New MAC Working Key
Algorithm	AN 1	The approved algorithm for which the protected key may be used. Possible values: A – AES D – DEA (DES) E – Eliptic Curve H – HMAC-SHA-1 R – RSA S – DSA T – Triple DES (TDEA) Valid Values: 'T'
Mode of Use	AN 1	Defines the operation the protected key can perform. For example, a MAC key may be limited to verify-only. Possible values: B – Both Encrypt and Decrypt/ Wrap & Unwrap C – Both Generate and Verify D – Decrypt/Unwrap only E – Encrypt/ Wrap only G – Generate only N – No special restrictions S – Signature only V – Verify only X – Key used to derive other keys(s) Valid Values: ‘B’ = Used for New PIN Working Key ‘C’ = Used for New MAC Working Key
Key Version Number	N 2	Two-digit ASCII character version number, optionally used to indicate that contents of the key block is a component, or to prevent re- injection of old keys. Valid Values: '00' - Key Versioning is not used for this key.
Exportability	AN 1	Defines whether the protected key may be transferred outside the cryptographic domain in which the key is found. E - May only be exported in a trusted key block, provided the wrapping key itself is in a trusted format N - Non-exportable S - Sensitive; all other export possibilities are permitted, provided such export has been enabled Valid Values: 'E'
Number of Optional Blocks	N 2	Defines the number of Optional Blocks included in the key block. PayNet does not support optional Key Block. Valid Values: '00'
Reserved	N 2	This field is reserved for future use. Valid Values: '00'
ENCRYPTED KEY DATA
Field Name	Format	Description
Encrypted Key Data	ANS ..72	Contains the encrypted Key Data (PIN or MAC Working Key). Variable length data, depending on the key length.
ENCRYPTED KEY DATA
Field Name	Format	Description
MAC	AN 8	Contains the Message Authentication Code of the Header and Encrypted Key Data.

S-120 Key Management

S-120	Key Management	Format: ANS 9 (includes a 3-position data element length indicator)
PayNet Key Management contains check digits for key exchanges. This data element is conditional for network management messages. It must be included in the message if the Network Management Information Code (S-70) is set to 162, 163, or 164. The structure of S-120 is provided below. Included for each field is the field’s position in the element, its field length, and a description of its contents. This data element is set either by member banks or PayNet.
Position	Length	Description
01 - 03	3	Field Length Indicator This field must be set to 006.
04 -09	6	Check Digits The check digits for the key being exchanged. PayNet will only populate the first 4 digits of the Check Digits into this sub-field. The last 2 digits always padded with zeroes.

S-123 Cryptographic Service Message

S-120	Cryptographic Service Message	Format: ANS ...553(includes a 3-position data element length indicator)
Cryptographic Service Message (CSM) contains the ANSI X9.17 standard cryptographic service message. This message is used to pass CSM data in dynamic key management messages. This data element is set by PayNet or member banks. The Cryptographic Service Message is conditional for network management messages. It must be included in the message if the Network Management Information Code (S-70) is set to 161, 162, or 163. This Data Element should be omitted from the 0800 New Key request message and 0810 New Key response message when TR-31 Key Block is implemented. The structure of this data element is provided below.
Position	Length	Description
001 - 003	3	Field Length Indicator This data element must contain the length of the Cryptographic Service Message (CSM).
004 -553	550	Cryptographic Service Message (CSM) This field contains the Cryptographic Service Message (CSM). The length of this field depends on the format of the CSM being sent or received. Refer to the Cryptographic Service Message in Section 6 for details on the way PayNet products use the CSM.