HSBC ISO 20022 XML MESSAGE IMPLEMENTATION GUIDE

Customer Credit Transfer Initiation v2 Payment Status Report v2

Version 1.7, 10th May 2013

International Organization for Standardization ISO 20022 Universal financial industry message scheme

HSBC ISO 20022 CCTI Message Implementation Guide 2 of 33

CONTENTS

1.

Introduction .................................................................................................................................... 4 1.1. 1.2. 1.3. 1.4. 1.5. Use of this Document................................................................................................................ 4 Scope ........................................................................................................................................ 4 Further documents .................................................................................................................... 4 XML Basics ............................................................................................................................... 4 Occurrences: ............................................................................................................................. 5

2.

Message Details ............................................................................................................................. 6 2.1. 2.2. 2.3. Message Overview ................................................................................................................... 6 Supported Character Sets and Local Language ...................................................................... 7 Message Transfer and Application Headers ............................................................................ 8

3.

Message Core ................................................................................................................................. 9 3.1. Group Header ........................................................................................................................... 9 Authorisation choice ........................................................................................................ 10

3.1.1. 3.2.

PaymentInformation Block ...................................................................................................... 11 Payment Type Information <PmtTpInf> ........................................................................... 12

3.2.1. 3.3.

CreditTransferTransactionInformation Block <CdtTrfTxInf> ................................................... 13 Payment Identification <PmtId> ....................................................................................... 15 Amount <Amt> ................................................................................................................. 15 Exchange Rate Information <XchgRateInf> .................................................................... 16 Regulatory Reporting <RgltryRptg> ................................................................................ 16 Tax <Tax> ........................................................................................................................ 17 Related Remittance Information <RltdRmtInf> ................................................................ 18 Remittance Information <RmtInf> .................................................................................... 19

3.3.1. 3.3.2. 3.3.3. 3.3.4. 3.3.5. 3.3.6. 3.3.7. 3.4.

General Comments ................................................................................................................. 20 Financial Institutions ........................................................................................................ 20 Accounts .......................................................................................................................... 21 Parties .............................................................................................................................. 22 Addresses ........................................................................................................................ 23

3.4.1. 3.4.2. 3.4.3. 3.4.4. 3.5.

Sample Files ........................................................................................................................... 23

HSBC ISO 20022 CCTI Message Implementation Guide 3 of 33

4.

Payment Concepts ....................................................................................................................... 24 4.1. 4.2. 4.3. 4.4. 4.5. Payment Instruments .............................................................................................................. 24 Value Dates and Cut-off Times ............................................................................................... 24 Batching .................................................................................................................................. 25 Reference Numbers and Reconciliation ................................................................................. 25 Duplicate Check ...................................................................................................................... 27

5.

Payment Status Report ................................................................................................................ 27 5.1. Status Messages .................................................................................................................... 27 Use of Status Messages .................................................................................................. 27 Message Format .............................................................................................................. 28

5.1.1. 5.1.2. 5.2. 5.3. 5.4.

Group Header <GrpHdr> ........................................................................................................ 28 Original Group Information and Status <OrgnlGrpInfAndSts> ............................................... 29 Transaction Information and Status <TxInfAndSts> ............................................................... 30 Status Reason Codes ...................................................................................................... 31

5.4.1. 5.5.

Additional Services ................................................................................................................. 31 Instructions to the Bank ................................................................................................... 31

5.5.1. 6.

Core Message Fields ................................................................................................................... 32 6.1. 6.2. Low-value Payments (ACH).................................................................................................... 32 High-value Payments (Priority Payments) .............................................................................. 33

HSBC ISO 20022 CCTI Message Implementation Guide 4 of 33

1.

Introduction

1.1. Use of this Document

This document describes the message formats used to initiate payments at HSBC using the ISO 20022 XML message set. It outlines the message scenario, message structure, and any general core country or instrument requirements. This document is supplemented with a series of regional and product specific appendices covering any additional country or local instrument requirements. It is targeted at customers wishing to implement XML payment messages with HSBC.

1.2. Scope
HSBC supports a number of payment instruments via the ISO 20022 Customer Credit Transfer Initiation message and the associated status report. High Value Payments, Low Value Payments, SEPA, COS & Faster Payments. For further details, please contact your HSBC representative.

Payment Type

Description

High Value Payment (HV)

Priority wire payments (which can be cross-border payments or domestic wire payments)

Low Value Payment (LV)

Domestic ACH payment

SEPA

Single Euro Payments Area

COS

Cheque Outsourcing Service

Faster Payments (FP)

Low Value same day payments for the UK only

1.3. Further documents

Further documents are available on the ISO 20022 message set from ISO and Swift. The ISO XML Payment Standards Initiation has been defined through the message registration process in accordance with ISO 20022. The format definition can be viewed on www.iso20022.org and the site also provides a summary document on the formats of the Customer Credit Transfer Initiation (CCTI) message and Payment Status Report (PSR) The following message definition is based on version 2 of the CCTI message - pain.001.001.02 and version 2 of the PSR - pain.002.001.02

1.4. XML Basics

XML stands for Extensible Markup Language and is a semi-structured file format that allows data and data element descriptions to be in the same container, e.g. a file. The actual data is encapsulated between a start and an end tag; it may itself consist of tags, forming a logical tree structure. In a well-formed XML document a definition which describes minimum requirements for an XML document that allow correct handling by generic parsers and renderers there is exactly one root tag to the document and all data is enclosed within tags. Each tag that is opened must be closed, and the last opened tag must be closed first. The tags are set in between a less than and a greater than sign, such that the following pattern is created: <tag>content</tag>. As in all tree structures, two tags where one directly belongs to the other, can be called parent and child tag, respectively. The ultimate parent tag is called root. There is only one root tag in well-formed XML messages.

HSBC ISO 20022 CCTI Message Implementation Guide 5 of 33

Tags that only contain other tags are sometimes called components, while tags that contain data are called elements. Sample tree structure Root Parent Child1 Child2 XML representation <Root> <Parent> <Child1>content</Child1> <Child2>content</Child2> </Parent> </Root>

The ISO 20022 XML standards each use a schema to define the basic layout of the XML message, including the tag names, the indication of mandatory elements, the field type and length, and potentially supported values. Schema conformance can be verified with any off-the-shelf XML editor that supports schema verification, such as Microsoft XML Notepad (based on .NET Framework 2.0; free download from http://www.microsoft.com/downloads/details.aspx?familyid=72d6aa49-787d-4118-ba5f4f30fe913628&displaylang=en Further information and links on XML can be found at http://en.wikipedia.org/wiki/XML

1.5. Occurrences:
Occurrences This indicates whether an element is optional or mandatory and how many times the element can be repeated. The number of occurrences is shown between square brackets For example: [0..1] shows that the element can be present 0 times or 1 time. The element is optional [1..1] shows that the element can be present only 1 time. The element is mandatory [1..n] shows that the element can be present 1 to n times The element is mandatory An element which is part of a set of elements, is mandatory as far as the set it is part of, is present in the message. If only one of several elements may be present, this is indicated by XOR in the status column

HSBC ISO 20022 CCTI Message Implementation Guide 6 of 33

2.

Message Details

2.1. Message Overview

The diagram below shows the main building blocks of Customer Credit Transfer Initiation message, which is defined as schema <pain.001.001.02>:

Notes on this message structure: 1. A single Group Header (Block A) may have multiple (1n) Payment Information Components (Block B) within it. Each Payment Information Component may have multiple (1n) transactions (the Credit Transfer Transaction Information component-block C) within it. 2. The term Payment Instruction is used to refer to the combination of building block B-Payment Information (i.e. the debit side of a payment instruction) + building block C-Credit Transfer Transaction Information (i.e. the credit side of a payment instruction). One Customer Credit Transfer Initiation message can contain one or more Payment Instructions. So, within each message there will be exactly one Group Header, followed by one or more Payment Information blocks. These blocks each represent a batch of payments that share the same debit information (debit account, execution date). Each Payment Information block will contain one or more Credit Transfer Transaction Information blocks, which define the credit information (amount, beneficiary, remittance information). In line with SWIFT guidelines, one message is allowed per file and only one message type is allowed per file for file-based interfaces to HSBC connect. The file should start with an xml and a Document tag, the latter containing the CCTI message. In describing the hierarchical structure of the data presentation in XML, this guide uses diagrams created with Altova XMLSpy software. The following symbols are used; Solid lines or frames indicate mandatory elements; optional elements use broken lines. Fields that are not used or supported by HSBC have been greyed out. If tags may repeat, the number of repetitions is noted under the box denoting that tag. Frames around groups of fields indicate a complex data type as defined in the XML schema. The name of the data type is printed in the upper left corner of the frame. The symbol indicates a sequence of fields that may occur within a certain tag. One or more of the stated sub-tags may be used. Note that the tag order that must be observed is always top to bottom. The symbol indicates a choice of fields. Only one item from the choice may be

HSBC ISO 20022 CCTI Message Implementation Guide 7 of 33

selected. Below is a sample diagram. The tag RfrdDocInf itself is optional within its given context. It may have two sub-components RfrdDocTp and RfrdDocNb. If RfrdDocTp is used, one (and only one) of the tags Cd or Prtry must be provided; additionally the tag Issr may be used. Diagrammatic representation Possible XML representation <RfrdDocInf> <RfrdDocTp> <Cd>CINV</Cd> <Issr>ISO</Issr> </RfrdDocTp> <RfrdDocNb>12345689</RfrdDocNb> </RfrdDocInf> Please note that HSBC will accept the over-population of fields. This is to say, if a piece of information is not required for the payment but present in the file, it will be ignored and not rejected. This approach allows clients to more easily reuse messages designed for other banks and to standardise their message layout.

2.2. Supported Character Sets and Local Language

The supported characters in the ISO XML message are limited to digits as well as lower-case and uppercase Latin characters plus special characters as defined in the character set for Swift MT messages. The expected encoding is Unicode UTF-8. For the Latin character set, commonly used in international communication, HSBC supports the following characters: abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ 0123456789 /-?().,' Space Please note that XML is a character based format. All field sizes are in characters, regardless of the size in bytes that a character takes up. Characters that are used in the XML syntax are not allowed within fields. They need to be replaced by their entity symbol, a symbolic name enclosed in a starting ampersand and trailing semicolon. The following table lists these characters.
Character Name Less than sign Greater than sign Ampersand Quotation Mark Apostrophe Character < > & Entity Symbol &lt; &gt; &amp; &quot; &apos;

Entity symbols are used as single characters within an XML element if the text to be entered includes any of the above characters. A name tag containing the text Marks&Spencer, for instance, would read <Nm>Marks&amp;Spencer</Nm>. At this stage, HSBC is currently only converting the ampersand and the apostrophe. If you are planning to use any of the other characters, you will need to advise your implementation manager as soon as possible.

HSBC ISO 20022 CCTI Message Implementation Guide 8 of 33

2.3. Message Transfer and Application Headers

HSBC is using a simple application header for the payment initiation message in line with the ISO samples. The XML start tag indicates the XML version (which currently is always 1.0) and the code page used with the message. The document tag provides the single root element for the well-formed XML message and indicates the name space of the message. The name space in the example below (set under attribute xmlns) identifies a Customer Credit Transfer Initiation V2 message. The message will be formatted like this. <?xml version="1.0" encoding="UTF-8" ?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.001.02" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <pain.001.001.02> <!-- Your message goes here --> </pain.001.001.02> </Document> For additional details on XML formatting and name space handling, please refer to the defintions provided by the World Wide Web Consortium (W3C) at http://www.w3.org/XML/Core/.

Codes
R

Term
Required

Definition
Standard element for HSBC / CGI; Required by HSBC / CGI

Explanation
This element is required by some or all of the CGI supporting banks. An "R" field may represent a piece of data that some of the banks do not need for processing, but have agreed that the client may send. This element needs to be present when certain conditions apply. This is an element that may be required. The need to populate it will vary. This element is not used by HSBC. The field may be present and will be ignored. Select one or the other field, but not both

Conditional

Standard element for HSBC / CGI; Dependent upon a certain condition. Standard element for HSBC. Dependent upon a certain condition. Not used by HSBC but maybe required by CGI. Standard element for CGI. Contents are XOR either by the schema or CGI usage.

Optional

NU XOR

Not Used Exclusive Or

CGI Stands for Common Global Implementation

HSBC ISO 20022 CCTI Message Implementation Guide 9 of 33

3.

Message Core

3.1. Group Header

The group header contains information pertaining to the entire message. The Initiating Party is required as per the ISO 20022 standard; for HSBC the Identification is used to indicate the HSBC Connect Customer ID. The Customer ID is mandatory and is used by HSBC Connect to identify the message sender. It will be provided during implementation

HSBC ISO 20022 CCTI Message Implementation Guide 10 of 33

R* At least one must be present

Ref 1.1 1.2 1.3

Name MessageIdentification CreationDateTime Authorisation

Tag <MsgId> <CreDtTm> <Authstn>

Occurrences [1:1] [1:1] [0:2]

Format/ (Max Length) Char(35) ISODate Time Char(35)

Remarks Unique message reference used with status messages returned for the processing of this file. Time stamp of the message creation. AUTH, FDET, FSUM or ILEV. AUTH defaulted if not used. Please see section 3.1.1 for full details. Not used. Please refer to section 4.4 for a description of which reference numbers can be reported on the bank statement in which case. Number of transactions in the entire message. This will be verified against the number of occurrences of <CdtTrfTxInf> in the message Hash total of all payment amounts regardless of currency. If provided, this will be verified. Structure indication of the file, Always use code MIXD for HSBC. Provide HSBC Connect Customer ID in Bank Party ID field. Alternatively, the following can be provided: BEI under <InitgPty><Id> <OrgId><BEI> or SIRET ID under <InitgPty><Id><OrgId><PrtryId><Id>. HSBC Connect Customer ID

Status R R O

1.4

BatchBooking

<BtchBookg>

[0..1]

Char(5)

NU

1.5

Number of Transactions

<NbOfTxs>

[1:1]

Numchar (15) Amount (18)

1.6

Control Sum

<CtrlSum>

[0:1]

1.7

Grouping

<Grpg>

[1..1 ]

Char(4)

1.8

Initiating Party

<InitgPty>

[1:1]

Complex data type

InitiatingParty.Identifica tion.OrganisationIdentifi cation.BankPartyIdentifi cation InitiatingParty.Identifica tion.OrganisationIdentifi cation.BEI InitiatingParty.Identifica tion.OrganisationIdentifi cation.ProprietaryIdenti fication. Identification

<InitgPty><Id> <OrgId><BkPt yId> <InitgPty><Id> <OrgId><BEI> <InitgPty><Id> <OrgId><PrtryId ><Id>.

[0:1]

Char(35)

R*

[0:1]

Char(35)

Customer's BIC

R*

[0:1]

Char(35)

SIRET ID

R*

R* At least one must be present

3.1.1. Authorisation choice

CODE
AUTH

NAME
PreAuthorisedFile

Description
Indicates a file has been pre authorised or approved within the originating customer environment and no further approval is required Indicates that a file requires additional file level approval in HSBCnet, with the ability to view both the payment information block and supporting customer credit transaction detail. Indicates that a file requires additional file level approval in HSBCnet, with the ability to view only the payment information block level information. PaymentInformationId is mandatory at this authorisation level and should be unique within a file if multiple batches are used. Indicates that a file requires all customer transactions to be authorised or approved independently in HSBCnet.

FSUM

FileLevelAuthorisation Summary

FDET

FileLevelAuthorisationDetails

ILEV

InstructionLevelAuthorisation

AUTH defaulted if not used.

HSBC ISO 20022 CCTI Message Implementation Guide 11 of 33

3.2. PaymentInformation Block

The payment information block contains the debit information and one or more transactions.

Ref. 2.1

Name PaymentInformation Identification

Tag <PmtInfId>

Occurrence s [1..1]

Field Format (Max Length) Char(35)

Remarks Batch reference number. This reference will be the debit reference reported on the account statement when the transactions are processed as a batch (low value payments). Possible values: TRF or TRA for electronic payments; CHK for paper-based instruments. Cheques are covered in a separate product appendix. See section 3.2.1 Date on which the payment should be executed or the cheque be issued. Name of the account holder of the debit account must be provided. See section 3.4.3 for details on parties. Account number of the debit account must be provided. See section 3.4.2 for details on accounts. Swift BIC and/or local bank code of the HSBC branch servicing the debit account must be provided. See section 3.4.1 for details on Financial Institutions. Name of the party owing the money may be provided if different from debtor. See section 3.4.3 for details on parties. Accepted values: DEBT, SHAR, CRED Indicates who should bear transaction charges. Depending on type of payment, some options may be invalid. See section 3.3 for details

Status R

2.2

PaymentMethod

<PmtMtd>

[1..1]

Code(3)

2.3 2.13

PaymentType Information RequestedExecution Date Debtor

<PmtTpInf> <ReqdExctnDt>

[0..1] [1..1]

Complex data type ISO date

O R

2.15

<Dbtr>

[1..1]

Complex data type Complex data type Complex data type

2.16 2.17

DebtorAccount DebtorAgent

<DbtrAcct> <DbtrAgt>

[1..1] [1..1]

R R

2.19

UltimateDebtor

<UltmtDbtr>

[0..1]

Complex data type Char(4)

2.20

ChargeBearer

<ChrgBr>

[0..1]

2.23

CreditTransfer TransactionInformation

<CdtTrfTxInf>

[1..n]

Complex data type

HSBC ISO 20022 CCTI Message Implementation Guide 12 of 33

3.2.1. Payment Type Information <PmtTpInf>

The payment type information defines the payment instrument to be used more specifically than the payment method is able to. Payment type information can be given at PaymentInformation level (reference numbers 2.3 to 2.12) or at transaction level (reference numbers 2.27 to 2.36). It may only be given in one of these two places within one PaymentInformation block. Typically, bulk payments (e.g. ACH payments or cheques) would specify the payment type at PaymentInformation level, single payments (e.g. wire payments) may use either level.

Ref.

Name

Tag

Occurrence s

Field Format (Max Length) Char(4) Not used.

Remarks

Status

2.4

InstructionPriority

<InstrPrty>

[0..1]

NU

2.5

ServiceLevel

<SvcLv>

[0..1]

Complex data type

Only option Code is used.

2.6

ServiceLevel.Code

<SvcLv><Cd>

[1..1]

Char(4)

Possible values: SEPA for SEPA payments. PRPT and SDVA for high value payments. Possible values: MPNS for low value payments, RTGS or RTNS for high value payments. Instrument code to more closely define a HSBC or in-country specific payment method. If used, the relevant codes are described in the regional appendices to this guide. Purpose of the payment. Supported codes are as per ISO definition.

R*

2.8

ClearingChannel

<ClrChanl>

[0..1]

Complex data type

R*

2.10

LocalInstrument.Proprie tary

<LclInstrm><Prtry >

[0..1].[1..1]

Char(4)

2.12

CategoryPurpose

<CtgyPurp>

[0..1]

Code

*Note: (R) = one of these items should be present for electronic payments (payment method = TRF or TRA).

HSBC ISO 20022 CCTI Message Implementation Guide 13 of 33

3.3. CreditTransferTransactionInformation Block <CdtTrfTxInf>

The CreditTransferTransactionInformation block contains all information for the actual payment and the beneficiary party. The number of occurrences of this block in the message equals the number of payment transactions to be executed. The transaction information refers to the debit information of the PaymentInformation block it is belonging to. It allows the user to redefine some properties of the transaction, such as the Ultimate Debtor. If provided at both levels, the transaction level will take precedence. Please note that not all properties available at both PaymentInformation and transaction level may be used concurrently. The payment type information may only be present at one of these levels (see PaymentTypeInformationRule in the ISO Message Definition Report); similarly, the ChargeBearer is limited to one of the two levels.

HSBC ISO 20022 CCTI Message Implementation Guide 14 of 33

Occurrence s Field Format (Max Length) Complex data type Complex data type Complex data type Complex data type

Ref.

Name

Tag

Remarks

Status

2.24

PaymentIdentification

<PmtId>

[1..1]

See section 3.3.1 for details Payment type information may be provided here if not specified at PaymentInformation level. This is only valid for high value payments (wires). See section 3.3.2 for details The ExchangeRate or an FX contract reference may be provided if pre-agreed. See section 3.3.3 for details. Accepted values: DEBT, SHAR, CRED Indicates who should bear transaction charges. Depending on type of payment, some options may be invalid. If not used, HSBC will default to SHAR Please see the separate COS Product Appendix for further details Name of the party owing the money may be provided if different from debtor. See section 3.4.3 for details on parties. Ultimate debtor may alternatively be specified at transaction level but not both. Intermediary agent if required for the payment. This information should only be provided if specifically requested by the payee. Account of the intermediary agent with HSBC if relevant. Beneficiary bank. See section 3.4.1 for details on data that can identify a financial institution. Account of the creditor agent with the intermediary agent if relevant. See section 3.4.2 for details on account data. Name, Address, and additional identification of the beneficiary of the payment (account holder of the beneficiary account). See section 3.4.3 for details on parties. Beneficiary account. See section 3.4.2 for details on account data. Name of the party to whom the funds are due. This information should only be provided if different to the creditor. Instructions for the beneficiarys bank can be sent for high-value payments.

2.27

PaymentType Information

<PmtTpInf>

[0..1]

2.37

Amount

<Amt>

[1..1]

2.42

ExchangeRate Information

<XchgRateInf>

[0..1]

2.46

ChargeBearer

<ChrgBr>

[0..1]

Code

O R (CHK only)

2.47

ChequeInstruction

<ChqInstr>

[0..1]

Complex data type

2.48

UltimateDebtor

<UltmtDbtr>

[0..1]

Complex data type

2.49

IntermediaryAgent1

<IntrmyAgt1>

[0..1]

Complex data type Complex data type Complex data type Complex data type Complex data type Complex data type Complex data type Complex data type

2.50

IntermediaryAgent1 Account

<IntrmyAgt1Acct>

[0..1]

2.55

CreditorAgent

<CdtrAgt>

[0..1]

R*

2.56

CreditorAgentAccount

<CdtrAgtAcct>

[0..1]

2.57

Creditor

<Cdtr>

[0..1]

R*

2.58

CreditorAccount

<CdtrAcct>

[0..1]

R*

2.59

UltimateCreditor

<UltmtCdtr>

[0..1]

2.60

InstructionForCreditor Agent InstructionForDebtor Agent

<InstrForCdtrAgt>

[0..n]

2.63

<InstrForDbtrAgt>

[0..1]

Char(140)

See Regional appendix

2.67

RegulatoryReporting

<RgltryRptg>

[0..10]

Complex data type Complex data type Complex data type Complex data type

See section 3.3.4 for general details. Please see Regional Appendices for usage rules. See section 3.3.5 for general details. Please see Regional Appendices for usage rules. See section 3.3.6 for general details. Please see Advising Product Appendix for further details. See section 3.3.7 for general details. Please see Advising Product Appendix for further details.

2.76

Tax

<Tax>

[0..1]

2.77

RelatedRemittance Information

<RltdRmtInf>

[0..10]

2.84

RemittanceInformation

<RmtInf>

[0..1]

HSBC ISO 20022 CCTI Message Implementation Guide 15 of 33

3.3.1. Payment Identification <PmtId>

The Payment Identification tag allows the originator to specify two reference numbers for the transaction. Where used, the Instruction ID is viewed as the customer to bank reference. In line with industry agreement, the EndToEndID is used to reference the payment for all parties (including the beneficiary). See section 4.4 (reference numbers and reconciliation) and section 4.5 (duplicate checking) for further details.

Ref.

Name

Tag

Occurrence s

Field Format (Max Length)

Remarks

Status

2.25

PaymentIdentification InstructionIdentification

<InstrId>

[0..1]

Char(35)

Transaction identication between ordering party and the bank. Transaction identification throughout the payment processing, including the beneficiary. It is strongly recommended to limit the end-to-end ID to digits and uppercase Latin characters up to a maximum length of 12 characters to maximise chances of the ID being carried through all bank and clearing systems.

2.26

PaymentIdentification EndToEndIdentification

<EndToEndId>

[1..1]

Char(35)

3.3.2. Amount <Amt>

The payment amount can be given either in payment currency (InstructedAmount) or in the account currency with instructions to pay in a different currency (EquivalentAmount). Both options are supported by HSBC, although EquivalentAmount should only be used with high-value payments. Current or agreed exchange rates apply when the payment currency is different from the account currency. Country conditions apply. Please check regional appendices.

Ref.

Name

Tag

Occurrence s

Field Format (Max Length)

Remarks Payment amount in payment currency. The currency must be provided in the mandatory attribute Ccy. The number of significant decimals may not be greater than the currency allows.

Status

2.38

Amount InstructedAmount

<InstdAmt>

[1..1]

Amount(18,5)

R*

HSBC ISO 20022 CCTI Message Implementation Guide 16 of 33

Occurrence s Field Format (Max Length)

Ref.

Name

Tag

Remarks Payment amount in account currency. The currency must be provided in the mandatory attribute Ccy. The number of significant decimals may not be greater than the currency allows. ISO code of the payment currency

Status

2.40

Amount EquivalentAmount Amount EquivalentAmount CurrencyOfTransfer

<EqvtAmt><Amt>

[1..1]

Amount(18,5)

R*

2.41

<EqvtAmt><CcyO fTrf>

[1..1]

Char(3)

Note: Either the InstructedAmount field or both EquivalentAmount fields are required.

3.3.3. Exchange Rate Information <XchgRateInf>

If an exchange rate has been pre-agreed with HSBC, the contract reference or rate can be specified with the payment. The option is currently supported together with an indication of the EquivalentAmount only.

Ref.

Name

Tag

Occurrence s

Field Format (Max Length)

Remarks

Status

2.43

ExchangeRate Information ExchangeRate ExchangeRate Information ContractIdentification

<XchgRate>

[0..1]

Amount(1,10)

The agreed exchange rate as a base-one rate (up to 10 decimals, 11 digits maximum length). The Foreign Exchange trade contract number.

2.45

<CtrctId>

[0..1]

Char(35)

3.3.4. Regulatory Reporting <RgltryRptg>

This section provides guidance on the structure of the Regulatory reporting information section. Bearing in mind the local nature of Regulatory Reporting, further details concerning usage, are contained in the Regional Appendices.

HSBC ISO 20022 CCTI Message Implementation Guide 17 of 33

Occurrence s Field Format (Max Length)

Ref.

Name

Tag

Remarks

Status

2.68

DebitCreditReporting Indicator

<DbtCdtRptgInd>

[0..1]

Char(4)

Refer to Regional Appendix

2.69

Authority

<Authrty>

[0..1]

Complex data tye

Refer to Regional Appendix

2.72

RegulatoryDetails.Code

<RgltryDtls> <Cd> <RgltryDtls> <Amt> <RgltryDtls> <Inf>

[0..1]

Char(3)

Refer to Regional Appendix

2.73

RegulatoryDetails Amount RegulatoryDetails. Information

[0..1]

Amount

Refer to Regional Appendix

2.75

[0..n]

Char(35)

Refer to Regional Appendix

3.3.5. Tax <Tax>

This section provides guidance on the structure of the Tax information section. Further details concerning usage are contained in the Regional Appendices.

Ref.

Name

Tag

Occurrence s

Field Format (Max Length)

Remarks

Status

7.1.0

CreditorTaxIdentification

<CdtrTaxId>

[0..1]

Char(35)

Refer to Regional Appendix for usage rules

7.1.1

CreditorTaxType

<CdtrTaxTp>

[0..1]

Char(2)

Refer to Regional Appendix for usage rules

7.1.2

DebtorTaxIdentification

<DbtrTaxId>

[0..1]

Char(35)

Refer to Regional Appendix for usage rules

7.1.3

TaxReferenceNumber

<TaxRefNb>

[0..1]

Char(15)

Refer to Regional Appendix for usage rules

7.1.4

TotalTaxableBase Amount

<TtlTaxblBaseAm t>

[0..1]

Amount(18,5)

Refer to Regional Appendix for usage rules

7.1.5

TotalTaxAmount

<TtlTaxAmt>

[0..1]

Amount(18,5)

Refer to Regional Appendix for usage rules

7.1.6

TaxDate

<TaxDt>

[0..1]

ISODate

Refer to Regional Appendix for usage rules

7.1.7

TaxTypeInformation

<TaxTpInf>

[0..1]

Complex data type

Refer to Regional Appendix for usage rules

HSBC ISO 20022 CCTI Message Implementation Guide 18 of 33

3.3.6. Related Remittance Information <RltdRmtInf>

The Related Remittance Information section allows the user to define recipients for payment advices. Please refer to the Advising Product Appendix for full details.

Ref.

Name

Tag

Occurrence s

Field Format (Max Length)

Remarks

Status

2.78

RemittanceIdentification

<RmtId>

[0..1]

Char(35)

Refer to Advising Appendix

2.79

RemittanceLocationMet hod RemittanceLocationElec tronicAddress RemittanceLocationPost alAddress.Name RemittanceLocationPost alAddress.Country

<RmtLctnMtd>

[0..1]

Char(4)

Refer to Advising Appendix

2.80

<RmtLctnElctrncA dr> <RmtLctnPstlAdr ><Nm> <RmtLctnPstlAdr ><Ctry>

[0..1]

Char(256)

Refer to Advising Appendix

2.82

[0..1]

Char(70)

Refer to Advising Appendix

2.83

[0..1]

Char(2)

Refer to Advising Appendix

HSBC ISO 20022 CCTI Message Implementation Guide 19 of 33

3.3.7. Remittance Information <RmtInf>

The Remittance Information section contains information about the purpose of the payment. Typically, only limited information can be sent with the payment (payment details) due to restrictions in the clearing systems. The amount of information that can be sent with payment details varies from payment type to payment type. For high-value payments, for instance, payment details of 4 lines of 35 characters are supported; the first line is required to transmit the end-to-end ID. Consequently, 3 lines of 35 characters can be used, which can be provided in the unstructured section, with HSBC providing the required line wrapping capability. HSBC also operates an advising service, which allows the customer to include the associated payment details within the tags in this section, and HSBC will forward a full payment advice to the beneficiary via fax, email, or regular mail. Further details are contained in the Advising Product Appendix.

Ref.

Name

Tag

Occurrence s

Field Format (Max Length)

Remarks Payment details; available space depending on payment instrument. Note that part of the payment details will be used to transmit the end-to-end identification of the payment.

Status

2.85

RemittanceInformation. Unstructured

<RmtInf><Ustrd>

[0..n]

Char(140)

HSBC ISO 20022 CCTI Message Implementation Guide 20 of 33

Occurrence s Field Format (Max Length) Complex data type

Ref.

Name

Tag

Remarks

Status

2.86

RemittanceInformation. Structured

<RmtInf><Strd>

[0..n]

Please refer to the Regional Appendices, COS MIG, or the Advising MIG.

3.4. General Comments

3.4.1. Financial Institutions
Financial Institutions are structured alike throughout the message. The following diagram shows the field structure that is relevant for the Forwarding Agent, the Debtor Agent, the Charges Account Agent, the Intermediary Agents, as well as the Creditor Agent. The financial institutions can be identified by their SWIFT BIC, a local clearing code, a proprietary code, their name and address, or a combination of these. In line with the recently published SWIFT XML rulebook, HSBC now only supports the CombinedIdentification option. HSBC will select the appropriate financial institution identification required for the payment instrument. Please note that the supporting regional appendices highlight any local requirements concerning the identification of the underlying financial institution.

HSBC ISO 20022 CCTI Message Implementation Guide 21 of 33

The SWIFT BIC can be an eight or eleven character string identifying the financial institution. A catalogue of BICs is published by SWIFT at http://www.swift.com/biconline/index.cfm?fuseaction=display_freesearch. The Clearing System Member Identification is the local (typically domestic) clearing code, such as a sort code in the UK or a Bankleitzahl in Germany. If the Code option is used, a 5-char prefix is required. The prefix can be generic (fixed value XXXXX) or clearing system specific (e.g. DEBLZ for German Bankleitzahl). A list of valid prefixes is published in the ISO/CSTP Message Usage Guide. When using name and address to indicate the bank, observe the comments on address formatting in section 3.4.4. To identify the ordered bank (debtor agent) the BIC or the domestic clearing code are required, depending on the payment instrument. It is important to review the in-country rules in the regional appendices concerning the use of the domestic clearing code for the Debtor Agent, as in some countries, this must not be provided. Please note: HSBC requires the country code of both the debtor and creditor agent, which must be quoted in the Postal Address section located under Combined Identification.

3.4.2. Accounts
Accounts can be identified by different codes, such as an International Bank Account Number (IBAN) or a domestic account number. The account structure also allows the type of the account, the currency of the account and the account holder to be stated.

International Bank Account Numbers (IBAN) need to be provided in the IBAN tag; for domestic account numbers use the ProprietaryAccount/Identification tag. Whilst the underlying schema contains an XOR restriction under the ID section of Cash Account 7, which means only one of the two account numbers may be present, HSBC has developed some additional flexibility, which allows customers to provide both the proprietary and the IBAN, if these are already maintained in the master vendor record. This approach will simplify the XML implementation by reducing the internal filtering logic. If you intend to take advantage of this flexibility, it is important that you check your other banking providers can also support this flexibility. HSBC does not support BBAN and UPIC tags at present. The type of account may be relevant in some countries (e.g. the USA, which distinguishes between checking and savings accounts). Further information can be found in the Regional Appendices. The currency and account holder of the account are not relevant; if provided they will be ignored.

HSBC ISO 20022 CCTI Message Implementation Guide 22 of 33

3.4.3. Parties
All parties involved in the payment, such as the initiating party, the debtor, or the creditor, can be indicated using the same field structure. The requirements will differ between parties; more information is typically required for debtor and creditor while other parties may be excluded from the message.

The name of the party can be specified with up to 70 characters. Depending on the payment instrument and clearing system used, further restriction may apply and the name may be truncated during processing. A postal address of the party can be indicated. For details on address handling please refer to section 3.4.4. Indentification numbers can be stated for the party; organisations and private persons are differentiated. For organisation IDs, one instance of OrgId with a set of optional identifications can be included. For private identifications, the PrivateIdentification tag may repeat up to 4 times with exactly one ID each. It is

HSBC ISO 20022 CCTI Message Implementation Guide 23 of 33

acceptable to use the same ID multiple times (e.g. a passport number) if distinct values are provided (i.e. the person has more than one passport).

3.4.4. Addresses
Postal addresses in the ISO XML messages support a lot of information, more than can typically be forwarded through a clearing system or printed on a cheque. The following guidelines should be observed when populating address fields.

Up to 5 occurrences of AddressLine can provide a formatted or unstructured address. Alternatively, a structured address can be provided using the street name, building number, post code, town name, and country sub-division (e.g. a county or state) tags. If structured addresses are provided, AddressLine can be used to provide additional name lines or a building name etc.; it may not repeat any information already contained in the structured part of the address. That is to say, either a structured or an unstructured address may be provided, but not both at the same time. Since printing and forwarding of address data is limited, often to 4 lines of 35 chars, HSBC recommend you limit the address information to the essential components to avoid truncation. If an address is provided, the country code becomes mandatory. It is required even if a formatted address is provided.

3.5. Sample Files

Please refer to your Implementation Manager for Country specific sample files.

HSBC ISO 20022 CCTI Message Implementation Guide 24 of 33

4.

Payment Concepts

4.1. Payment Instruments

In most countries, different payment instruments are available to effect payments. They are distinguished by the way the payment is made and the number of characters for the payment information, eg invoice numbers The main differentiation in payments is whether they are electronic payments or paper-based payments. For electronic payments the settlement is via direct bank communication or a clearing system; the customer is notified of the debit or credit on his account via the bank statement. For paper-based payments a document is issued to the beneficiary or a specified third party and is used to settle the payment (by presenting the document at the beneficiarys bank). This general differentiation is reflected in the payment method (tag 2.2) of the Customer Credit Transfer Initiation message; TRF and TRA indicate an electronic payment, CHK a paper-based payment. Within the electronic payments, there are two major types: high-value payments (also: wire payments) and low-value payments (also: ACH payments). High-value payments are single payments and are reported individually on the bank statement. They are usually of higher value than the ACH payments and the settlement cycle is shorter. High value payments may be indicated as urgent, in which case they are usually settled on the same day (depending on cut-off times). High-value payments can be both domestic and international payments. Low-value payments are bulk payments where a single debit on the account of the ordering party is offset against the single entries for the beneficiaries involved. They are generally non-urgent and of lower value than the wire payments. Low-value payments are almost always restricted to domestic payments, as domestic clearing systems are used in the settlement of the payments. Paper-based payments are usually either cheques or bank drafts. Both issue a paper document to the beneficiary or a third party detailing the amount and applicable restrictions (permissible recipient of the money, time frame the document may be handed in, documents such as a proof of delivery that must be presented at the time of paying-in the cheque or draft). Cheques are drawn against the account of the ordering party at the time they are paid, whilst drafts are drawn against the ordered bank and may be debited from the ordering party account at the time of issue. Each of these categories may be sub-divided into more payment types depending on local practice, but there is no general rule that can be applied. In the USA, for instance, several types of low-value payments exist that differ mainly in the amount of information that can be sent with the payment. The Nordic countries differentiate between several payment details formats that indicate the type of reference number passed to the beneficiary. In France, an electronic version for letters of credit (VCOM) exists in addition to the classic paper-based ones.

4.2. Value Dates and Cut-off Times

The XML message does not have a specific field for the value date of the transaction. The date that is provided with each transaction is the RequestedExecutionDate (tag 2.13). It defines the day the payment is initiated and the funds debited from the ordering party account, or the day the cheque is cut. Depending on clearing cycles, the beneficiary will receive the funds the same day or one or more days later. Weekends and bank holidays are not usually considered for payment processing and should not be specified in the payment instruction. If given, the next available workday will be selected for payment processing. Full details of the cut-off times for the countries currently supported are contained in the regional appendices.

HSBC ISO 20022 CCTI Message Implementation Guide 25 of 33

4.3. Batching
For any bulk payments that have one debit and multiple credits (equal a batch), especially for low value payments, some restrictions apply which need to be considered during file creation. All transactions within the batch must have the same debit account and the same requested execution date. This is guaranteed by the file structure and the file generation process will need to group payments by their debit side information. All transactions within the batch must be local payments in local currency for low-value payments. Low-value and high-value payments must not be grouped into one batch together. Hign value payments within a file can be in any tradable currency and for any destination account. In the XML Customer Credit Transfer Initiation message, a batch equals a Payment Information section with all the transactions contained therein. It is strongly recommended to assign a batch reference number to all batches of payment instructions sent to HSBC. The batch reference number is provided in the field PaymentInformationIdentification (tag 2.1) and, for low value payments, will be reported on the bank statement. Instructions that will be processed as individual transactions by the banking system, for instance high value payments, the transaction reference (end-to-end identification) will be reported on the bank statement. Batch reference numbers (PaymentInformationIdentification (tag 2.1) will be ignored for this type of payment instruction.

4.4. Reference Numbers and Reconciliation

The ISO XML messages contain several reference numbers that support different scenarios for payment reconciliation. This is primarily true for the reconciliation of the ordering party; the beneficiary will always receive the end-to-end identification, subject to both the in-country clearing system and beneficiary bank having the capability to support this reference. The MessageIdentification <MsgId> (reference) is used to uniquely identify each file. It is also returned in the payment status report at both the file and transaction status level. The MessageIdentification (tag 1.1) is mandatory. For Low Value payments, the batch reference is reported on the bank statement of the ordering party. It is also specified in the associated payment status report at a transaction-level, if provided in the payment instruction. The XML field is PaymentInformationIdentification <PmtInfId> (tag 2.1). which is optional but recommended by HSBC. There are two reference numbers for the transaction. The InstructionIdentification <InstrId> (tag 2.25) is used between the ordering party and HSBC only and is returned in the payment status message and additionally, there is an option to receive this on the bank statement of the ordering party (see below). The EndToEndIdentification <EndToEndId> (tag 2.26) is used in all messages related to the payment. It is provided in transaction-level status messages and on the bank statement of the beneficiary, subject to the clearing system and beneficiary bank being able to support this information. Additionally, there is an option to receive this on the bank statement of the ordering party (see below). It is the only payment information reference that will be passed through the clearing system onto the beneficiary. Depending on internal customer usage rules, this may contain either invoice related information, policy details or a unique remittance identifier which will be supported by a separate remittance advice to assist in the beneficiarys reconciliation process. Finally, depending on the underlying payment method, HSBC can pass through additional payment related information which is sourced from the field RemittanceInformationUnstructured <RmtInf><Ustrd> (tag 2.85).

HSBC has also introduced some additional flexibility concerning the ordering customer statement reference in respect of HV (priority) payments. This option reflects the fact that there is not normally a common transaction reference that is meaningful to both ordering and beneficiary parties. Implemented as part of the

HSBC ISO 20022 CCTI Message Implementation Guide 26 of 33

customer set-up process, HSBC can either report the InstructionIdentification <InstrId> or EndToEndIdentification <EndToEndId> as the debit reference on the bank statement of the ordering party.

HSBC ISO 20022 CCTI Message Implementation Guide 27 of 33

Please be aware that the successful reconciliation of bulk debits for batch payments may require an integration of the status messages into the reconciliation process. For example, one or more transactions within a batch may be rejected due to a validation failure. The amount debited to the account will therefore be less than the original batch total. The status messages (which will be sent before the bank statement) will report any such rejections and will allow for a correction of the expected debit amount on the bank statement. High value payments will be reported on the bank statement if they are valid and could be paid in full.

4.5. Duplicate Check

Duplicate checking is a service HSBC offers for payment instructions to ensure that a payment instruction is not inadvertently processed more than once. The check uses the transaction reference number and the debit account number. This combination must yield a unique identification. The storage and verification of transaction reference numbers is limited to a period of three months. If within that timeframe a duplicate reference number appears on the account, the new transaction is rejected and a (negative) status message sent to the ordering party. HSBC has introduced some additional flexibility concerning the duplicate process in respect of all payments. This approach reflects the potential uniqueness issues surrounding a common transaction reference. For example, some payments, including salary and insurance payments typically have a fixed reference. Implemented as part of the customer set-up process, HSBC can either support duplicate payment instruction checking using either the InstructionIdentification <InstrId> or EndToEndIdentification <EndToEndId>, but not both. Please note that if you select the Instruction Identification, you will need to confirm that your other banking partners have the flexibility to support this logic. A further duplicate check is done on the file reference number (MessageIdentification <MsgId>, tag 1.1) to prevent the same file from being processed multiple times. This check cannot be deactivated. The message identification needs to be unique over a period of three months at least. HSBC recommends the reference is unique for a 12 monthly rolling period.

5.

Payment Status Report

5.1. Status Messages

5.1.1. Use of Status Messages
Status messages are used to report the success or failure of messages sent. There are two levels at which the processing status is reported. The message level. Here the receipt of the Customer Credit Transfer Initiation message is confirmed and the processing status specifies if the message could be handled correctly or if there were any syntax errors that led to the rejection of the entire message. The transaction level. Here the processing of individual transactions is reported. If the transaction is rejected, the status message will contain an error code and description to explain why the transaction could not be processed. For positive status messages, the status ACCP (accepted) will be used. Please note there may be multiple status messages for a single transaction if positive status messages are activated; the last message sent will contain the current status and update any previous status indication. For each level, the client can select to receive error messages only or both error and success messages. The scope of messages to be sent by HSBC is set up in the client profile. Here the information necessary to send the status messages (protocol, server, target directory, user and password, etc.) will be held as well. Status messages will refer to the underlying message or transaction by its reference numbers. For this reason it is helpful to assign unique reference numbers during creation of the CCTI message and to

HSBC ISO 20022 CCTI Message Implementation Guide 28 of 33

retain these reference numbers along with the relevant document links for automated (or manual) processing. Please see section 4.4 for a description of the available reference numbers.

5.1.2. Message Format

The status message is structured into three blocks. The Group Header is present exactly once and identifies the status message context. In the Original Group Information and Status block the inbound (payment) message that is being reported on is referenced and a general status may be provided. The Transaction Information and Status block is optional and repetitive and can indicate the status of particular transactions. HSBC uses a subset of the ISO 20022 message to report the payment status. The relevant fields are outlined below.

5.2. Group Header <GrpHdr>

The group header contains a unique message reference and the time stamp of its creation. It also references the HSBC connect Customer ID.

Ref.

Name

Tag

Occurrence s

Field Format (Max Length) Char(35)

Remarks

Status

1.1

MessageIdentification

<MsgId>

[1..1]

Unique message reference of the status message.

1.2

CreationDateTime InitiatingParty.Identificati on.OrganisationIdentific ation.BankPartyIdentific ation

<CreDtTm>

[1..1]

ISODateTime

Time stamp of the message creation. HSBC Connect Customer ID in Bank Party ID field. Alternatively, the following can be provided: BEI under <InitgPty><Id> <OrgId><BEI> or SIRET ID under <InitgPty><Id> <OrgId><PrtryId><Id>.

1.3

<InitgPty><Id> <OrgId><BkPtyId >

[1..1]

Char(35)

HSBC ISO 20022 CCTI Message Implementation Guide 29 of 33

Note that Mandatory with the status message means that the information is always provided.

5.3. Original Group Information and Status <OrgnlGrpInfAndSts>

The Original Group Information and Status block references the inbound message (e.g. the payment instruction message) whose status is being reported. For message level acknowledgements (EDIFACT equivalent: CONTRL), it also contains the processing status of the message and any relevant error messages.

Ref.

Name

Tag

Occurrence s

Field Format (Max Length) Char(35)

Remarks Message reference of the related message. For the purposes of this guide the message reference of the payment instruction message. Indicates the type of message referred to. For payment instructions the value is pain.001.001.02.

Status

2.1

OriginalMessageIdentifi cation OriginalMessageNameI dentification OriginalCreationDateTi me OriginalNumberOfTrans actions

<OrgnlMsgId>

[1..1] option

2.3

<OrgnlMsgNmId>

[1..1]

Char(35)

2.4

<OrgnlCreDtTm>

[0..1]

ISODateTime Time stamp of the original message.

2.6

<OrgnlNbOfTxs>

[0..1]

Numchar(15)

Number of transactions of the original message.

2.7

OriginalControlSum

<OrgnlCtrlSum>

[0..1]

Amount

Hash total of the original message. Code that specifies the file status. If the file is valid: ACCP If the file is invalid: RJCT HSBC connect file level error rejection code. This applies only when GroupStatus is RJCT. Description of error code for file level errors if applicable (i.e. if GroupStatus is RJCT).

2.8

GroupStatus

<GrpSts>

[0..1]

Char(4)

2.13

StatusReason. Proprietary AdditionalStatusReason Information

<StsRsn><Prtry>

[0..1].[1..1]

Char(35)

2.14

<AddtlStsRsnInf>

[0..n]

Char(105)

HSBC ISO 20022 CCTI Message Implementation Guide 30 of 33

5.4. Transaction Information and Status <TxInfAndSts>

Transaction information is provided for transaction level reporting (EDIFACT equivalent: BANSTA). It contains references and selected values of the original transaction together with a status indication.

Ref.

Name

Tag

Occurrence s

Field Format (Max Length) Char(35)

Remarks

Status

3.1

StatusIdentification

<StsId>

[0..1]

Unique HSBC batch and transaction reference.

3.2

OriginalPaymentInforma tionIdentification OriginalInstructionIdentif ication OriginalEndToEndIdenti fication

<OrgnlPmtInfId>

[0..1]

Char(35)

Original unique identification of the payment information block. Original unique identification of the original instruction within the customer transfer transaction block. Original unique end to end identification of the original instruction within the customer transfer transaction block.

3.3

<OrgnlInstrId>

[0..1]

Char(35)

3.4

<OrgnlEndToEndI d>

[0..1]

Char(35)

HSBC ISO 20022 CCTI Message Implementation Guide 31 of 33

Ref. Name Tag Occurrence s Field Format (Max Length) Char(35) Remarks Code that specifies the transaction status. If the transaction is valid: ACCP If the transaction is invalid: RJCT HSBC connect transaction level error rejection code. This applies only when TransactionStatus is RJCT. Description of error code for transaction level errors if applicable (i.e. if TransactionStatus is RJCT). Original instructed amount of the payment if applicable. Original equivaluent amount of the payment if applicable. Original currency of transfer for the equivalent amount of the payment if applicable. Mandatory

3.6

TransactionStatus

<TxSts>

[0..1]

3.11

StatusReason. Proprietary AdditionalStatusReason Information OriginalTransactionRefe rence.Amount. InstructionAmount OriginalTransactionRefe rence.Amount.Equivale ntAmount.Amount OriginalTransactionRefe rence.Amount.Equivale ntAmount.CurrencyOfTr ansfer RequestedExecutionDat e

<StsRsn><Prtry>

[0..1].[1..1]

Char(35)

3.12

<AddtlStsRsnInf>

[0..n]

Char(105)

3.20

<OrgnlTxRef> <Amt><InstdAmt> <OrgnlTxRef> <Amt><EqvtAmt> <Amt> <OrgnlTxRef> <Amt><EqvtAmt> <CcyOfTrf> <ReqdExctnDt>

[0..1].[1..1]

Amount

3.22

[0..1].[1..1]

Amount

3.23

[0..1].[1..1]

Char(3)

3.25

[0..1]

ISODate

Original execution date requested for the payment.

3.103

Creditor

<Cdtr>

[0..1]

Complex data type

Name of the creditor on the original transaction.

5.4.1. Status Reason Codes

A full list of related error codes in respect of the file and instruction level validation is available from your Integration Manager.

5.5. Additional Services

5.5.1. Instructions to the Bank
Specific instructions can be sent to the debtor or creditor bank within the XML message. Multiple instructions are supported for the creditor bank in tag 2.60 InstructionsForCreditorAgent and its sub-tags. The instruction code list is limited by ISO 20022 to the following code words. Additional information for the instruction, such as a phone number to call, can be provided in InstructionInformation (tag 2.62). CHQB - PayCreditorByCheque: (ultimate) creditor must be paid by cheque. HOLD - HoldCashForCreditor: Amount of money must be held for the (ultimate) creditor, who will call. Pay on identification. PHOB PhoneBeneficiary: Please advise/contact (ultimate) creditor/claimant by phone. TELB Telecom: Please advise/contact (ultimate) creditor/claimant by the most efficient means of tele-communication. Please note that the transfer of instructions to the beneficiary bank depends on the clearing system used and can therefore vary between different payment types. It is not common to use instructions with low-value payments for instance. Please contact your Implementation Manager to verify if instructions can be supported in a given scenario. Instructions to the debtor bank that is: to HSBC can be provided in tag 2.63. Currently, no special code words are supported.

HSBC ISO 20022 CCTI Message Implementation Guide 32 of 33

6.

Core Message Fields

6.1. Low-value Payments (ACH)

The following table lists the core fields relevant to any ACH payment and their respective place within the XML payment initiation message. Its purpose is to help the user locate and understand the most important fields of the XML message, which may be useful if your development includes a core message template. For a detailed structure description, please refer to section 3 above.
Ref. Name BankPartyIdentification (HSBC Connect Customer ID) Debtor Ordering Party Name (and Address) Debit Account (Ordering Party Account) DebtorAgent Ordered Bank (HSBC branch) Tag <InitiatingParty><Identificat ion><OrganisationIdentific ation><BankPartyIdentifica tion> <Dbtr> Complex Remarks Provide HSBC Connect Customer ID in Bank Party ID field. Alternatively, the following can be provided: BEI under <InitgPty><Id> <OrgId><BEI> or SIRET ID under <InitgPty><Id> <OrgId><PrtryId><Id>. The ordering party name and address are required. The name is limited to 35 chars, the address to 4 lines of 35 chars. The debit account should always be provided as a domestic account number in ProprietaryAccount/Identification. The IBAN can be used in some countries, please see regional appendices BIC of the HSBC branch. Status

1.8

2.15

2.16

<DbtrAcct><Id><PrtryAcct ><Id>

2.17

<DbtrAgt> Complex <DbtrAgt> <FinInstnId> <CmbndId> <PstlAdr> <Ctry> <CdtrAgt> <FinInstnId> <CmbndId> <BIC> <ClrSysMmbId> <Nm><PstlAdr> <CdtrAgt> <FinInstnId> <CmbndId> <PstlAdr> <Ctry> <Cdtr> Complex

4.1.33

Debtor Agent/Country (Ordered Bank Country) CreditorAgent Beneficiary Bank Creditor Agent/Country (Beneficiary Bank Country) Creditor Beneficiary Name (and Address)

The ISO country code of the ordering The BIC of the beneficiary bank, domestic clearing code and the name and address of the bank may be provided. However, the domestic clearing code is required for domestic ACH Processing, unless advised otherwise in the regional appendices. The ISO country code of the beneficiary bank

2.55

4.1.33

2.57

HSBC recommends you provide the beneficiary name which will be passed through as part of the local in-country clearing system format. Domestic account number is normally required, unless advised otherwise in the regional appendix. Preferred Payment Method is TRF (Electronic transfer), but TRA (Electronic transfer with return advice) can be supported, although the advice is dependent on the in-country back office capability. Preferred: ClearingChannel is MPNS (Mass Payment Net System). Alternatively, the following ServiceLevel code will be supported: SEPA SingleEuroPaymentsArea This field can be used for duplicate instruction checking. This option is available as part of the customer set-up process. Please note: Where the HSBC Advising service is used, the InstructionIdentification must be unique across the first 12 digits and is mandatory. It is strongly recommended to provide this reference number. This reference will be the debit reference reported on the account statement for the total value of the transactions within the batch, where it is a logical batch, for example ACH. . This field can be used for duplicate instruction checking and is available as part of the customer set-up. It is recommended to provide an EndTtoEndIdentification reference of max. 12 characters and to limit the characters to digits and Latin uppercase chars. Day the ACH payment is to be initiated. Clearing cycles and cut-off times should be observed. Amount and currency of the transaction. For ACH payments the currency must be the respective domestic currency; for SEPA it must be EUR.

2.58

CreditorAccount (Beneficiary Account)

<CdtrAcct><Id><PrtryAcct ><Id><IBAN>

2.2

PaymentMethod

<PmtMtd>

2.3 or 2.27

Payment TypeInformation with at least one of the elements ServiceLevel or ClearingChannel.

<PmtTpInf><SvcLvl><Cd> OR <PmtTpInf><ClrChanl>

2.25

InstructionIdentification

<InstrId>

2.1

PaymentInformationIdentif ication

<PmtInfId>

2.26

EndToEndIdentification

<EndToEndId>

2.13

RequestedExecutionDate InstructedAmount (Payment Amount)

<ReqdExctnDt>

2.38

<Amt><InstdAmt>

HSBC ISO 20022 CCTI Message Implementation Guide 33 of 33

6.2. High-value Payments (Priority Payments)

The following table lists the core fields relevant to any RTGS payment and their respective place within the XML payment initiation message. It has been introduced into the document to help the user locate and understand the most important fields of the XML message. For a detailed structure description, please refer to section 3 above.
Ref. Name BankPartyIdentification (HSBC Connect Customer ID) DebtorAgent Ordered Bank (HSBC branch) Tag <InitiatingParty><Identifi cation><OrganisationIde ntification><BankPartyId entification> <DbtrAgt> Complex <DbtrAgt> <FinInstnId> <CmbndId> <PstlAdr> <Ctry> <Dbtr> Complex Remarks Status

1.8

The HSBC Connect customer ID is required for all payments sent to HSBC Connect to identify the sending party and the relevant profile. BIC of the HSBC branch. You have the option to additionally provide the domestic clearing code.

2.17

4.1.33

Debtor Agent/Country (Ordered Bank Country) Debtor Ordering Party Name (and Address) Debit Account (Ordering Party Account)

The ISO country code of the ordering bank

2.15

The ordering party name and address are required. The name is limited to 35 chars, the address to 4 lines of 35 chars. The debit account should always be provided as a domestic account number in ProprietaryAccount/Identification. The IBAN can be used in some countries, please see regional appendices. BIC of the beneficiary bank, domestic clearing code and the name and address of the bank may be provided.

2.16

<DbtrAcct><Id><PrtryAc ct><Id> <CdtrAgt> <FinInstnId> <CmbndId> <BIC> <ClrSysMmbId> <Nm><PstlAdr> <CdtrAgt> <FinInstnId> <CmbndId> <PstlAdr> <Ctry> <Cdtr> Complex

2.55

CreditorAgent Beneficiary Bank Creditor Agent/Country (Beneficiary Bank Country) Creditor Beneficiary Name (and Address)

4.1.33

The ISO country code of the beneficiary bank The beneficiary name needs to be provided for all RTGS payments; providing an address is optional. The name is limited to 35 chars, the address to 4 lines of 35 chars. Domestic account number or IBAN of the target account. BIC of intermediary bank if required to provide by beneficiary. For alternative options please verify support with your Implementation Manager. Preferred Payment Method is TRF (Electronic transfer), but TRA (Electronic transfer with return advice) can be supported, but the advice is dependent on the in-country back office capability. Preferred: ClearingChannel is RTGS (Real Time Gross Settlement). Other Clearing Channel codes are supported: RTNS Real Time Net Settlement System BOOK Book Transfer Alternatively, the following ServiceLevel codes will be supported: PRPT EBA Priority Service SDVA Same Day Value This field can be used for both duplicate instruction checking and additionally, as the debit transaction reference on your bank statement. This option is available as part of the customer set-up and applies to RTGS (Urgent) instructions. This field can be used for both duplicate instruction checking and additionally, as the debit transaction reference on your bank statement. This option is available as part of the customer set-up and applies to RTGS instructions. Agreed exchange rate if EquivalentAmount is used.

2.57

2.58

CreditorAccount (Beneficiary Account)

<CdtrAcct><Id><PrtryAc ct><Id><IBAN>

2.49

IntermediaryAgent1

<IntrmyAgt1>

2.2

PaymentMethod

<PmtMtd>

2.3 or 2.27

Payment TypeInformation with at least one of the elements ServiceLevel or ClearingChannel.

<PmtTpInf><SvcLvl><C d> OR <PmtTpInf><ClrChanl>

2.25

InstructionIdentification

<InstrId>

2.26

EndToEndIdentification

<EndToEndId>

2.43

ExchangeRate

<XchgRateInf> <XchgRate>

2.45

ExchangeRateInformation. ContractIdentification

<XchgRateInf> <CtrctId> Deal reference for an FX contract. Use only if EquivalentAmount is used.

2.13

RequestedExecutionDate InstructedAmount (Payment Amount)

<ReqdExctnDt>

Day the RTGS payment is to be initiated. Clearing cycles and cut-off times should be observed. Amount and currency of the transaction either as instructed or equivalent amount (see section 3.3.2).

2.38

<Amt><InstdAmt>