TUPAS IDENTIFICATION SERVICE FOR SERVICE PROVIDERS Service Description and Service Provider’s Guidelines

Version 2.4 20 December 2013

1 (15)

Contents 1 Tupas service features ...................................................................................................................... 3

2 Service security ................................................................................................................................. 3

3 Functional description ....................................................................................................................... 4

4 Messages in the Tupas service ......................................................................................................... 5 4.1 Identification request ..................................................................................................... 5 4.2 Request fields ............................................................................................................... 6 4.3 Calculating the MAC for the identification request (A01Y_MAC).................................... 7 4.4 Return message (the Tupas certificate) and its identifier data ....................................... 7 4.5 Certificate data fields ..................................................................................................... 8 4.6 Calculating the MAC for the certificate........................................................................... 9 4.7 Identifier type ................................................................................................................. 9 4.8 Comparing the encrypted identifier .............................................................................. 10 4.9 Exceptions .................................................................................................................. 10

5 Changing the authentication key .................................................................................................... 11

6 Character set used in the service ................................................................................................... 12

APPENDIX 1 .......................................................................................................................................... 13

APPENDIX 2 – IDENTIFIER IN THE TUPAS CERTIFICATE ................................................................. 14

2 (15)

CHANGE LOG

Version Page Comment v2.0 Message structures changed v2.1 New banks added, some wording changed v2.2 New message fields and message field attributes. Check at your bank

whether the new attributes have been taken into use. v2.3 Name changed to Identification Service, the term “certification” abandoned.

Contact information and general description moved to Identification Principles. Added algorithm SHA-256.

v2.3b 5–8 Length of SHA-256 fixed. v2.3c 7 Implementation timeline of SHA-256 specified, maximum length of fields

B02K_CUSTID and B02K_USERID fixed. v2.4 8 Changes due to separation of Aktia, Savings Banks and Local Cooperative

Banks. APPROVED BY

v2.0 30 June 2002 Payment Systems Committee v2.1 3 October 2005 Payment Systems Committee v2.2 17 October 2006 Payment Systems Committee v2.3 15 March 2010 Payment Systems Committee v2.3c 20 January 2011 Payment Systems Committee v2.4 2 December 2013 Payment Systems Committee

3 (15)

1 Tupas service features The general description, administrative information, details of the service contract and the use of the service can be found in the document “Identification Principles of the Banks’ Tupas Identification Service”. The Tupas service has different features and functionalities depending on what kind of certification the service provider has agreed on with the bank in their mutual contract. The bank provides a certificate which always contains the customer’s name. The rest of the identification data can be either encrypted or plaintext. When the identification data is in plaintext format, the bank may provide the customer’s personal identity code (social security number), business identification code or other electronic identification code according to the service contract. A plaintext personal identity code will only be disclosed to service providers who have the rights to register it. When the identification data is encrypted, the response the bank sends the service provider contains the customer’s personal identity code, business identification code or other electronic transaction identifier. The identification code or number will however not be transmitted. Therefore the service provider must have the customer’s identification information to be able to use the bank’s certificate in the verification of the customer’s identity. If the service provider does not have the customer’s identifier, they must ask the customer to provide it before sending the identification request. This feature makes it possible for the service provider to verify the authenticity of the information supplied by the customer. The Tupas service is mainly applicable to consumer services. Some of the banks will also identify corporate customers through their business identification code, but not all will allow businesses to register as internet bank users, or provide the identification service for corporate customers. When corporate customers are identified, the bank’s certificate may disclose either the customer’s business identification code and the company’s name, or the customer’s business identification code and the company’s name in addition to the user’s name and personal identity code.

2 Service security The parties of the identification service communicate through the SSL protocol, which prevents third parties from viewing or changing any of the information. The service provider’s server software must support 128-bit SSL encryption keys. The length of the session key is determined on the basis of the customer’s browser. The data of the identification request and the certificate are encrypted with a message authentication code that ensures data integrity, which makes it impossible for the customer in control of the certificate transmission to alter the data without being noticed by the service provider or the bank. Each party is responsible for the encryption and security of their own services, and for the authenticity of the data they store. The customer using the identification service is responsible for keeping his/her bank identifiers from falling into the hands of any third parties.

4 (15)

3 Functional description

Explanation of the service’s functional description: 1. The customer using the identification service is connected to the service provider’s

service. The data connection between the customer and the service provider must be SSL-encrypted when the customer moves on to entering data into the identification service. During stages 2 to 7 the connection must always be SSL-encrypted.

2. The service provider sends the customer an identification request, which contains the transaction’s specification data. The customer verifies the data in the request, but cannot alter it. If desired, the customer can however abort the identification transaction and return to the original service. The identification request page on the customer’s browser contains a cancel button and buttons that take the customer to the different banks’ Tupas services.

3. The customer clicks on the button that transfers them to their own bank’s identification service. The bank receives an identification request which contains the required data on the service provider and the transaction. The bank verifies the integrity of the request and the authenticity of the data.

4. The bank sends the customer an identification request, if the service provider’s identification request is valid. If the bank notices errors in the identification request, the customer receives an error report and can use the cancel button to return to the service provider’s service.

5 (15)

5. The customer is identified using their bank’s identification service. The bank returns an error report to the customer if the identification fails, and the customer can return to the service with the cancel button.

6. After a successful identification the bank generates a Tupas certificate. The bank’s Tupas service activates the customer’s accept and cancel buttons.

7. The customer verifies the certificate’s data and accepts its transmission to the service provider. The customer can use the cancel button to abort the identification transaction and return to the service provider’s service.

8. The service provider verifies the integrity and uniqueness of the Tupas certificate they receive. The service provider attaches the certificate to the customer’s service transaction, and stores it for as long as other service data is stored. The customer’s identification data may not be registered or used for any other purposes.

4 Messages in the Tupas service

4.1 Identification request The data of the identification request is in the form of hidden variables in the FORM data group, behind the bank-specific button or icon.

FORM data group

Field Name of data Length Comment

1. Message type A01Y_ACTION_ID 3 - 4 Standard, "701" 2. Version A01Y_VERS 4 e.g. "0002" 3. Service provider A01Y_RCVID 10 - 15 Customer code 4. Service language A01Y_LANGCODE 2 ISO 639 identifier:

FI = Finnish SV = Swedish EN = English

5. Request identifier A01Y_STAMP 20 yyyymmddhhmmssxxxxxx 6. Identifier type A01Y_IDTYPE 2 see Appendix 1 7. Return address A01Y_RETLINK 199 OK return address for the certificate

8. Cancel address A01Y_CANLINK 199 Return address in the event of cancellation

9. Rejected address A01Y_REJLINK 199 Return address in error situations 10. Key version A01Y_KEYVERS 4 Key’s version data 11. Algorithm A01Y_ALG 2 01 = MD5 (no longer in use)

02 = SHA-1 (no longer in use) 03 = SHA-256

12. Control field A01Y_MAC 32 - 64 Message authentication code of the request

6 (15)

The data field titles are written in capital letters. The HTML structure of the FORM data group is:

<FORM METHOD=”POST” ACTION=”bank’s Tupas service URL”> <INPUT NAME=”A01Y_ACTION_ID” TYPE=”hidden” VALUE=”701”> <INPUT NAME=”A01Y_VERS” TYPE="hidden” VALUE=”...”> <INPUT NAME=”A01Y_RCVID” TYPE="hidden” VALUE=”...”> <INPUT NAME=”A01Y_LANGCODE” TYPE="hidden” VALUE=”...”> <INPUT NAME=”A01Y_STAMP” TYPE="hidden” VALUE=”...”> <INPUT NAME=”A01Y_IDTYPE” TYPE="hidden” VALUE=”...”> <INPUT NAME=”A01Y_RETLINK” TYPE="hidden” VALUE=”...”> <INPUT NAME=”A01Y_CANLINK” TYPE="hidden” VALUE=”...”> <INPUT NAME=”A01Y_REJLINK” TYPE="hidden” VALUE=”...”> <INPUT NAME=”A01Y_KEYVERS” TYPE="hidden” VALUE=”...”> <INPUT NAME=”A01Y_ALG” TYPE="hidden” VALUE=”...”> <INPUT NAME=”A01Y_MAC” TYPE="hidden” VALUE=”...”> </FORM>

4.2 Request fields Field 1 Message type, which is a standard “701” in the Tupas service.

Field 2 Bank-specific version number of the identification request message. Field 3 Service provider’s bank-specific customer code. The bank identifies the

service provider on the basis of the customer code and attaches the service provider’s registered name to the Tupas certificate.

Field 4 The language code indicates the language used on the service provider’s page, and the bank’s identification service is opened in this language.

Field 5 The service provider’s individual code for the request. The code can be a reference or customer number, or a combination of a running identifier, date, time and reference number.

Field 6 The identifier type indicates what kind of identifier the service provider wants from the customer using the identification service. The identifier type must correspond to the features specified in the service contract.

Field 7 The address of the page on the service provider’s site where the service continues to after successful identification. The service address must be SSL encrypted (https://). Example: VALUE=”https://product.merchant.fi/order/confirmation.htm”

Field 8 The continuation address in the event that the customer cancels the transmission of the certificate. Example: VALUE=”https://product.merchant.fi/order/cancel.htm”

Field 9 The continuation address if a technical error occurs during the identification transaction. The return address can be the same as for cancellation (field 8). Example: VALUE=”https://product.merchant.fi/order/error.htm”

Field 10 Key version used in MAC calculation.

7 (15)

Field 11 Type code of the algorithm used in MAC calculation. 01 = MD5 algorithm, which generates a 32-character MAC

02 = SHA-1 algorithm, which generates a 40-character MAC 03 = SHA-256 algorithm, which generates a 64-character MAC

The SHA-256 algorithm (code 03) was implemented in 2010. Codes 01 and 02 were abandoned in 2011.

Field 12 Message Authentication Code (MAC), which is calculated from the request data that is to be encrypted and the service provider’s authentication key, using the algorithm specified in field 11. The MAC enables the recipient of the certificate to verify the certificate’s sender and integrity.

4.3 Calculating the MAC for the identification request (A01Y_MAC) The service provider forms a bank-specific identification request for each bank button, and encrypts the request with a MAC. The MAC is calculated from the FORM data group of the request with the use of an authentication key the bank has given to the service provider. The calculation begins by forming a character string from the authentication key and the VALUEs of all the data fields that precede the MAC in the FORM data group (i.e. fields 1–11). The data is stringed in order so that all filler character blanks are left out. The data groups are separated by “&” (ampersand) in the string. The character “&” is also inserted between the last field (11) and the authentication key, and at the end of the MAC. The ampersands are included in the message’s MAC calculation. The data appears as a single line. Here the “↵” indicates a line break for the purposes of this document.

A01Y_ACTION_ID&A01Y_VERS&A01Y_RCVID&A01Y_LANGCODE&↵ A01Y_STAMP&A01Y_IDTYPE&A01Y_RETLINK&A01Y_CANLINK&↵ A01Y_REJLINK&A01Y_KEYVERS&A01Y_ALG&authenticationkey&

The calculated MAC is converted into hexadecimal form, and the hexadecimal hash value is placed into field 12. The letters A to F must be capitals in the character string.

4.4 Return message (the Tupas certificate) and its identifier data

Field Name of data Length Obligatory Comment

1. Version B02K_VERS 4 X e.g. "0002" 2. Certificate identification

B02K_TIMESTMP 23 X NNNyyyymmddhhmmssxxxxxx

3. Certificate number

B02K_IDNBR 10 X Number the bank has assigned to the certificate

4. Request identifier

B02K_STAMP 20 X Request data field 7 ( A01Y_STAMP)

5. Customer B02K_CUSTNAME - 40 X Name of identified person or company from the bank’s database

8 (15)

6. Key version B02K_KEYVERS 4 X Version of the key 7. Algorithm B02K_ALG 2 X 01 = MD5

02 = SHA-1 03 = SHA-256

8. Identifier B02K_CUSTID - 64 X see Appendix 2

9. Identifier type

B02K_CUSTTYPE 2 X see Appendix 2

10. User ID B02K_USERID - 64 R Corporate customer’s personal identity code or encrypted identifier; see Appendix 2

11. User name B02K_USERNAME - 40 R Corporate customer’s name, see Appendix 2

12. Control field

B02K_MAC 32 - 64 X The certificate’s MAC

The customer’s bank attaches the certificate data to the OK response link in query-string form.

http://A01Y_RETLINK?↵ B02K_VERS&B02K_TIMESTMP&B02K_IDNBR&B02K_STAMP&↵ B02K_CUSTNAME&B02K_KEYVERS&B02K_ALG&B02K_CUSTID&↵ B02K_CUSTTYPE&B02K_USRID&B02K_USERNAME&B02K_MAC

The data B02K_USRID and B02K_USERNAME are optional and only included when the identifier type value is “08” or “09”.

4.5 Certificate data fields Field 1 Version number of the certificate, bank-specific. Field 2 Timestamp formed by the bank’s system, in which NNN is the bank’s number:

Aktia = 410 * Bank of Åland = 600 Handelsbanken = 310 Local co-op banks = 430 * Nordea Bank Finland = 200 OP Bank Group = 500 S-Bank = 390 Sampo Bank = 800 Savings banks = 420 * Tapiola Bank = 360 *) The old shared code 400 can be used until 31 August 2014.

Field 3 The identifier the bank attaches to the certificate to identify it in the bank’s system.

Field 4 The identification request’s identifier, which is picked from the request’s data field 7 (A01Y_STAMP).

9 (15)

Field 5 Name of identified customer from the bank’s database. Field 6 The version information of the MAC authentication key. Field 7 Code of the MAC algorithm. Field 8 The customer’s identifier, which can be either an encrypted identifier or a

plaintext customer code depending on the contents of the A01Y_IDTYPE field in the identification request.

Field 9 Identifier type. Field 10 User ID. Corporate customer’s personal identity code or encrypted identifier;

see Appendix 2 Field 11 User name. Corporate customer’s name; see Appendix 2. Field 12 The Tupas certificate’s Message Authentication Code.

4.6 Calculating the MAC for the certificate The Message Authentication Code (BO2K_MAC) is calculated from the original message, after which Scandinavian and special characters (e.g. space, equal sign and quotation marks) are substituted with corresponding hexadecimal characters (e.g. %20 for space). The bank calculates the certificate’s MAC with a service provider specific authentication key. The MAC guarantees the service provider that the certificate has been formed by the customer’s bank and has not been tampered with. With identifier type values “00”–“07” the MAC is calculated from the response message’s data fields 1–9. In the calculation of the MAC the data and the authentication key are separated with “&”. The “&” symbol is also added after the authentication key. A service provider specific authentication key is used when the MAC is calculated. If the optional fields 10 and 11 are both empty, the code is not calculated for them and they are not be returned to the service provider.

B02K_VERS&B02K_TIMESTMP&B02K_IDNBR&B02K_STAMP&↵ B02K_CUSTNAME&B02K_KEYVERS&B02K_ALG&B02K_CUSTID&↵ B02K_CUSTTYPE&authenticationkey&

With identifier type values “08” and “09” the MAC is calculated from fields 1–11. The data and the authentication code are separated by the symbol “&”, which is also added after the authentication key. A service provider specific authentication key is used when the MAC is calculated.

B02K_VERS&B02K_TIMESTMP&B02K_IDNBR&B02K_STAMP&↵ B02K_CUSTNAME&B02K_KEYVERS&B02K_ALG&B02K_CUSTID&↵ B02K_CUSTTYPE&B02K_USRID&B02K_USERNAME&authenticationkey&

4.7 Identifier type The calculation of the certificate’s MAC is influenced by the type of identifier, defined in the A01Y_IDTYPE field of the identifier request.

10 (15)

4.7.1 Plaintext identifier The identification request’s field A01Y_IDTYPE contains value “02” or “03”, i.e. plaintext basic identifier or plaintext truncated identifier. The identifier is a plaintext string of characters, for example a personal identity code or its last four characters, according to the request’s field A01Y_IDTYPE. The identifier is placed as such into the response message’s field B02K_CUSTID.

4.7.2 Encrypted identifier The value in the identification request’s field A01Y_IDTYPE is “01”, i.e. encrypted basic identifier. The bank uses the same hash algorithm in the encryption as in the MAC calculation of messages. The uniqueness of the identifier is ascertained by including a customer identifier and additional data from the certificate’s data fields 2–4. The customer identifier is a personal ID code or a business ID code according to the identification request’s field 8 (A01Y_IDTYPE). While calculating the identifier, the data and the authentication key are separated with “&”, which is also added after the authentication key. A service provider specific key is used in the encryption.

B02K_TIMESTMP&B02K_IDNBR&B02K_STAMP&↵ customer_code&authenticationkey&

The result is converted into hexadecimal form, and the resulting character string is the customer’s identifier, which is placed in the certificate’s field B02K_CUSTID.

4.8 Comparing the encrypted identifier If the identifier is encrypted, the service provider will first verify the integrity of the Tupas certificate they have received. Next they will use the customer identifier in their register to calculate comparison data for the customer identifier that was described in section 4.7.2. If the calculated comparison data is identical to the identifier in the certificate, and the message is incorrupt, the bank’s information on the identified customer will match with the information in the service provider’s register.

4.9 Exceptions The service provider should prepare for exceptions, for example: 1. The customer interrupts the identification transaction

The customer may use the cancel button to interrupt the transaction either before the identification request has been received by the bank or after receiving the Tupas certificate. The cancel button’s address is specified in the identification request field 8.

2. Customer identification fails Customer identification can fail either because of erroneous customer identifiers, or because the customer has requested identification from the wrong bank. In this case

11 (15)

the customer uses the cancel button to return to the service provider’s service (address specified in the identification request field 8).

3. The bank notices an error in the identification request The bank notices an error in the identification request before the customer has been identified. The customer uses the cancel button to return to the service provider’s service (address specified in the identification request field 9).

4. The service provider notices an error in the Tupas certificate While verifying the certificate, the service provider notices an error, which may result from an error in the certificate’s data, or the information supplied by the customer does not match with the information in the bank’s register. In this case the service provider must notify the customer of the situation.

5. The request receives no response The failure may be caused by a connection error or another technical problem, or the customer has interrupted the transaction.

6. The same response is received multiple times The service provider must be prepared for the event that the customer sends the same response several times, or that the customer sends an old Tupas certificate while using the back/forward buttons in their browser.

5 Changing the authentication key The MAC key used in the calculation of authentication codes can be changed at the request of the bank or service provider. Bank-specific procedures are followed when the key is changed. The procedures are specified in the bank-specific service descriptions. There are two possible procedures for changing the key: • Only the authentication key is changed, and the service provider’s customer code

stays the same. • Both the authentication key and the customer code are changed.

The authentication key is sent to the contact person specified in the contract, along with the key’s version information and date of effect (after which the new key will be used in the calculation of authentication codes). To ensure that the key change goes fluently, the service provider’s system must allow the simultaneous use of at least two authentication keys, so that the new key can be entered into the system in advance. During the change there is a 15-minute timeframe when it is possible that some of the certificates received by the service provider have been calculated using the old key, and some using the new key. After the new key has been used successfully, the old key can be deleted or its use blocked in the service provider’s system.

12 (15)

6 Character set used in the service The service uses the following 8-bit ISO 8859-1 (Latin 1) character set.

æ %00 %01 %02 %03 %04 %05 %06 %07

0 1 2 3 4 5 6 7

%30 %31 %32 %33 %34 %35 %36 %37

` a b c d e f g

%60 %61 %62 %63 %64 %65 %66 %67

‘ ’ “ ” • – —

%90 %91 %92 %93 %94 %95 %96 %97

À Á Â Ã Ä Å Æ Ç

%c0 %c1 %c2 %c3 %c4 %c5 %c6 %c7

ð ñ ò ó ô õ ö ÷

%f0 %f1 %f2 %f3 %f4 %f5 %f6 %f7

backspace tab

linefeed

c return

%08 %09 %0a %0b %0c %0d %0e %0f

8 9 : ; < = > ?

%38 %39 %3a %3b %3c %3d %3e %3f

h i j k l m n o

%68 %69 %6a %6b %6c %6d %6e %6f

˜ ™ š › œ Ÿ

%98 %99 %9a %9b %9c %9d %9e %9f

È É Ê Ë Ì Í Î Ï

%c8 %c9 %ca %cb %cc %cd %ce %cf

ø ù ú û ü ý þ ÿ

%f8 %f9 %fa %fb %fc %fd %fe %ff

%10 %11 %12 %13 %14 %15 %16 %17

@ A B C D E F G

%40 %41 %42 %43 %44 %45 %46 %47

p q r s t u v w

%70 %71 %72 %73 %74 %75 %76 %77

¡ ¢ £ ¥ | §

%a0 %a1 %a2 %a3 %a4 %a5 %a6 %a7

Ð Ñ Ò Ó Ô Õ Ö

%d0 %d1 %d2 %d3 %d4 %d5 %d6 %d7

%18 %19 %1a %1b %1c %1d %1e %1f

H I J K L M N O

%48 %49 %4a %4b %4c %4d %4e %4f

x y z { | } ~

%78 %79 %7a %7b %7c %7d %7e %7f

¨ © ª « ¬ ¯ ® ¯

%a8 %a9 %aa %ab %ac %ad %ae %af

Ø Ù Ú Û Ü Ý Þ ß

%d8 %d9 %da %db %dc %dd %de %df

space ! " # $ % & '

%20 %21 %22 %23 %24 %25 %26 %27

P Q R S T U V W

%50 %51 %52 %53 %54 %55 %56 %57

€ ‚ ƒ „ … † ‡

%80 %81 %82 %83 %84 %85 %86 %87

° ± ² ³ ´ µ ¶ ·

%b0 %b1 %b2 %b3 %b4 %b5 %b6 %b7

à á â ã ä å æ ç

%e0 %e1 %e2 %e3 %e4 %e5 %e6 %e7

( ) * + , - . /

%28 %29 %2a %2b %2c %2d %2e %2f

X Y Z [ \ ] ^ _

%58 %59 %5a %5b %5c %5d %5e %5f

ˆ ‰ Š ‹ Œ Ž

%88 %89 %8a %8b %8c %8d %8e %8f

¸ ¹ º » ¼ ½ ¾ ¿

%b8 %b9 %ba %bb %bc %bd %be %bf

è é ê ë ì í î ï

%e8 %e9 %ea %eb %ec %ed %ee %ef

13 (15)

APPENDIX 1 The identifier type is specified in the identification request field 6. The type is coded with two characters XY as described below. The first character (X) specifies the contents of the requested identifier: 0Y = basic identifier 1Y = personal identity code 2Y = business identification code 3Y = personal ID code or business ID code 4Y = personal ID code and business ID code The second character specifies the form of the requested identifier: X1 = encrypted identifier

A hexadecimal MAC number which has been calculated from the customer’s identifier data.

X2 = plaintext identifier

The identifier can be the customer’s full identifier, which can be a personal identity code, an electronic user ID or a business ID code.

X3 = truncated identifier

The identifier can contain the last four characters of a personal identity code, or a complete business ID code.

N.B. Code 43 is not in use.

14 (15)

APPENDIX 2 – IDENTIFIER IN THE TUPAS CERTIFICATE The data field 9 of the response message (i.e. the certificate) indicates the identifier type. The data is coded using two characters, XY. The first character (X) indicates whether the requested customer information is found in the bank’s database. 0Y = The requested information was found. The message is returned to the specified return address. 00 = The identifier is unknown. The value “00” is used if no identifier is found. 01 = Plaintext personal ID code. The value “01” is used if a plaintext identifier has been requested, and only the

personal identity code is returned. Field 5 contains the customer’s name and field contains 8 the last four characters

of their personal identity code in plaintext. 03 = Plaintext business ID code. The value “03” is used if a plaintext identifier has been requested, and only the

business ID code is returned. Field 5 contains the company’s name and field 8 contains a plaintext business ID

code. 04 = Plaintext electronic identifier code. The value “04” is used if a plaintext identifier has been requested, and only an

electronic identifier code is returned. Field 5 contains the company’s name and field 8 contains the plaintext electronic

identifier code. 05 = Encrypted personal ID code. The value “05” is used if an encrypted identifier has been requested, and only the

personal identity code is returned. Field 5 contains the customer’s name and field 8 contains their encrypted

personal identity code. 06 = Encrypted business ID code. The value “06” is used is an encrypted identifier has been requested, and only the

business ID code is returned.

15 (15)

Field 5 contains the company’s name and field 8 contains their encrypted business ID code.

07 = Encrypted electronic identification code. The value “07” is used if an encrypted identifier has been requested, and only an

electronic identification code is returned (not used in Sampo). Field 5 contains the customer’s name and field 8 contains the encrypted

electronic ID code. 08 = Plaintext business ID code and corporate user’s plaintext personal ID code, or another

identifier specified in a mutual contract between the bank and the service provider. The value “08” is used if plaintext identifiers have been requested. Field 5 contains the company’s name,

field 8 contains the plaintext business ID code, field 10 contains the corporate user’s plaintext personal ID code and field 11 contains the corporate user’s name.

09 = Encrypted business ID code and corporate user’s encrypted personal ID code, or

another encrypted identifier specified in a mutual contract between the bank and the service provider.

The value “09” is used if encrypted identifiers have been requested. Field 5 contains the company’s name,

field 8 contains the encrypted business ID code, field 10 contains the corporate user’s encrypted personal ID code and field 11 contains the corporate user’s name.

1Y = All or some of the requested information could not be found. The data from the identifier type field (B02K_CUSTTYPE) is returned to the address specified in the “Rejected” field. The second character in the code of the identifier type indicates which of the customer information could not be retrieved. This allows the service provider to automatically send specific error notifications to the customer. 10 = No requested information on the customer. 11 = No personal ID code for the corporate customer. 12 = No business ID code for the corporate customer. Example: The service provider wants to find out the customer’s personal identity code, but the customer uses identifiers that only contain their business ID code. The bank sends the response message to the address in the “Rejected” field. In the response message the field 9 (identifier type) contains the value 11.