TUPAS IDENTIFICATION SERVICE FOR
SERVICE PROVIDERS
Service Description and Service Provider’s Guidelines
Version 2.3c
20 January 2011
1 (16)
Contents
1 Tupas service features ......................................................................................................................3
2 Service security .................................................................................................................................3
3 Functional description.......................................................................................................................4
4 Messages in the Tupas service ......................................................................................................... 6
4.1
Identification request ..................................................................................................... 6
4.2
Request fields ...............................................................................................................7
4.3
Calculating the MAC for the identification request (A01Y_MAC).................................... 8
4.4
Return message (the Tupas certificate) and its identifier data ....................................... 8
4.5
Certificate data fields ..................................................................................................... 9
4.6
Calculating the MAC for the certificate......................................................................... 10
4.7
Identifier type............................................................................................................... 10
4.8
Comparing the encrypted identifier .............................................................................. 11
4.9
Exceptions .................................................................................................................. 11
5 Changing the authentication key .................................................................................................... 12
6 Character set used in the service ................................................................................................... 13
APPENDIX 1 .......................................................................................................................................... 14
APPENDIX 2 – IDENTIFIER IN THE TUPAS CERTIFICATE ................................................................. 15
2 (16)
CHANGE LOG
Version
Page
Comment
v2.0
All
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
6–9
Length of SHA-256 fixed.
v2.3c
7–9
Implementation timeline of SHA-256 specified, maximum length of fields
B02K_CUSTID and B02K_USERID fixed.
APPROVED BY
v2.0
v2.1
v2.2
v2.3
v2.3c
30 June 2002
3 October 2005
17 October 2006
15 March 2010
20 January 2011
Payment Systems Committee
Payment Systems Committee
Payment Systems Committee
Payment Systems Committee
Payment Systems Committee
3 (16)
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 (16)
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 phases 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.
5 (16)
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. 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.
6 (16)
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
1. Message type
A01Y_ACTION_ID
2. Version
A01Y_VERS
4
3. Service provider
A01Y_RCVID
10–15
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
02 = SHA-1
03 = SHA-256
12. Control field
A01Y_MAC
3–4
32–64
Comment
Standard, "701"
e.g. "0002"
Customer code
Message authentication code of the
request
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=”...”>
7 (16)
<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.
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 transitional period during which the SHA-256 algorithm (code 03) will be
implemented and the codes 01 and 02 abandoned is between 1 April and 31
December 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.
8 (16)
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
Name of data
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
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
1
X = obligatory, required
R = at request only
Length
Obligatory
1
Field
Comment
9 (16)
9. Identifier
type
B02K_CUSTTYPE
2
X
see Appendix 2
10. User ID
B02K_USERID
–64
R
11. User name
B02K_USERNAME
–40
R
Corporate customer’s personal
identity code or encrypted
identifier; see Appendix 2
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:
Bank of Åland
Handelsbanken
Nordea Bank Finland
OP Bank Group
S-Bank
Sampo Bank
Savings banks and local co-op banks
Tapiola Bank
= 600
= 310
= 200
= 500
= 390
= 800
= 400
= 360
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).
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.
10 (16)
4.6
Field 9
Identifier type.
Field 10
User ID.
Field 11
User name.
Field 12
The Tupas certificate’s Message Authentication Code.
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.
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.
11 (16)
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
the customer uses the cancel button to return to the service provider’s service
(address specified in the identification request field 8).
12 (16)
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.
13 (16)
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
backspace
tab
linefeed
%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
%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
%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
{
|
}
~
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
€
(
)
*
+
,
.
/
%28
%29
%2a
%2b
%2c
%2d
%2e
%2f
X
Y
Z
[
\
]
^
_
%58
%59
%5a
%5b
%5c
%5d
%5e
%5f
c return
‚
ƒ
„
…
†
‡
ˆ
‰
Š
‹
Œ
Ž
%90
%91
%92
%93
%94
%95
%96
%97
À
Á
Â
Ã
Ä
Å
Æ
Ç
%c0
%c1
%c2
%c3
%c4
%c5
%c6
%c7
ð
ñ
ò
ó
ô
õ
ö
÷
%f0
%f1
%f2
%f3
%f4
%f5
%f6
%f7
%98
%99
%9a
%9b
%9c
%9d
%9e
%9f
È
É
Ê
Ë
Ì
Í
Î
Ï
%c8
%c9
%ca
%cb
%cc
%cd
%ce
%cf
ø
ù
ú
û
ü
ý
þ
ÿ
%f8
%f9
%fa
%fb
%fc
%fd
%fe
%ff
¥
|
§
%a0
%a1
%a2
%a3
%a4
%a5
%a6
%a7
Ð
Ñ
Ò
Ó
Ô
Õ
Ö
%d0
%d1
%d2
%d3
%d4
%d5
%d6
%d7
%78
%79
%7a
%7b
%7c
%7d
%7e
%7f
¨
©
ª
«
¬
¯
®
¯
%a8
%a9
%aa
%ab
%ac
%ad
%ae
%af
Ø
Ù
Ú
Û
Ü
Ý
Þ
ß
%d8
%d9
%da
%db
%dc
%dd
%de
%df
%80
%81
%82
%83
%84
%85
%86
%87
°
±
²
³
´
µ
¶
·
%b0
%b1
%b2
%b3
%b4
%b5
%b6
%b7
à
á
â
ã
ä
å
æ
ç
%e0
%e1
%e2
%e3
%e4
%e5
%e6
%e7
%88
%89
%8a
%8b
%8c
%8d
%8e
%8f
¸
¹
º
»
¼
½
¾
¿
%b8
%b9
%ba
%bb
%bc
%bd
%be
%bf
è
é
ê
ë
ì
í
î
ï
%e8
%e9
%ea
%eb
%ec
%ed
%ee
%ef
‘
’
“
”
•
–
—
˜
™
š
›
œ
Ÿ
¡
¢
£
14 (16)
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.
15 (16)
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.
16 (16)
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.