Danish Implementation Guideline for Common Global Implementation (CGI) Customer Payment Status Report

Transcription

1 Danish Implementation Guideline for Common Global Implementation (CGI) Customer Payment Status Report based on documentation from ISO Message Definition Report December 15th 2012 FINAL VERSION Page 1 of 66

2 Table of Contents INTRODUCTION 3 HOW TO READ THIS DOCUMENT 3 PART I 4 Functional definition 4 Overview 4 Scope 4 Message Flow 5 DANISH CGI MESSAGE DEFINITION 6 scope and goals 6 6 SECURITY 6 PART II 7 Message: CustomerPaymentStatusReportV03 (pain ) 7 MAIN CHARACTERISTICS 8 FORMAT SPECIFICATIONS 21 MESSAGE STRUCTURE - CUSTOMERPAYMENTSTATUSREPORT 22 Page 2 of 66

3 Introduction This Danish Message Implementation Guideline for Common Global Implementation of the CustomerPaymentStatusReport message is based on the Common Global Implementation MIG for CustomerPaymentStatusReport, the ISO Message Definition Report and the message CustomerPaymentStatusReport <pain >. The ISO Message Definition Report (MDR) and Message Usage Guideline (MUG) can be downloaded from: How to read this document The Message Definition, for the CustomerPaymentStatusReport, contains information intended for the financial institutions involved in the payment, as well as information directed to the payment initiator. The first part of this document will give some overview information concerning the of the CustomerPaymentStatusReport message. This part of the document includes information concerning the function and the scope of the CustomerPaymentStatusReport. The CustomerPaymentStatusReport message is sent by the financial institution executing the payment on the initiating party s account back to the initiating party. A selection of scenarios, where the CustomerPaymentStatusReport message can be applied, are presented under Message Flow below. Why a MIG? The scope and of the MIG is presented under the section Message Definition. The second part of the document includes information in the form of a table, concerning the characteristics of the message, the message structure, as well as the message content. This part of the document is intended for the technical side, implementing the CustomerPaymentStatusReport message. Within the section presenting the Message Structure, as well as within the section presenting Message Items Description, comments have been added, presenting the of the Items within the message. Note: The reader need to refer to the ISO CustomerPaymentStatusReport message in order to get the complete overview of the functionality of the message. Page 3 of 66

4 PART I Functional definition The CustomerPaymentStatusReport message is sent by the financial institution executing the payment on the initiating party s account back to the InitiatingParty. It is used to inform this party about the positive or negative status of an instruction (either single or file). It is also used to report on a pending instruction. Its will always be governed by a bilateral agreement between the agent and the nonfinancial institution customer. Overview Scope The set of CustomerCreditTransfer messages is exchanged between an Initiating Party or DebtorAgent. The set of messages covers the means to remit, manage and monitor CustomerCreditTransfer initiations from customers to their financial institutions. The messages are: 1. CustomerCreditTransferInitiationV03: used to initiate a credit transfer. It is sent by an InitiatingParty to a DebtorAgent. 2. CustomerPaymentStatusReportV03: used to report on the status of a credit transfer initiation. It is sent by a DebtorAgent to an InitiatingParty. Usage of this message is bilaterally agreed between the InitiatingParty and the DebtorAgent. 3. CustomerDirectDebitInitiationV03: used to request single or bulk transfer collection(s) of funds from one or various debtor's account(s) for a creditor. This implementation guideline covers the CustomerPaymentStatusReport V03. Page 4 of 66

5 Message Flow The CustomerPaymentStatusReport message is sent by the financial institution executing the payment on the InitiatingParty s account back to the InitiatingParty. For Customer Credit Transfers: On the initiating side (DebtorAgent), one role can be specified: the Debtor Agent, ie, the account servicing financial institution of the Debtor that sends the CustomerPaymentStatusReport On the receiving side, only one role can be specified: the InitiatingParty, ie, the party that receives the CustomerPaymentStatusReport from the DebtorAgent or ForwardingAgent, and who at first created the CustomerCreditTransfer message. Please note that ForwardingAgent is NOT suppoted by CGI. For Direct Debit Intiation: On the initiating side (CreditorAgent), one role can be specified: the Creditor Agent, ie, the account servicing financial institution of the Creditor that sends the CustomerPaymentStatusReport On the receiving side, only one role can be specified: the InitiatingParty, ie, the party that receives the CustomerPaymentStatusReport from the CreditorAgent or ForwardingAgent, and who at first created the DirectDebitInitiation message. Please note that ForwardingAgent is NOT suppoted by CGI. Page 5 of 66

6 Message Definition The Message Implementation Guideline is based on the CustomerPaymentStatusReport. If a Danish bank offer the service of a CustomerPaymentStatusReport it will be in accordance with this Message Implementation Guide. scope and goals - To develop harmonized "Bank to Customer Payment Status Report XML Message Implementation Guide (MIG)" for banks, banks' customers, software vendors in Denmark. - To assure the alignment of the Danish requirements with the Common Global Implementation and the global ISO 20022, Customer Payment Status Report standard. - Address the requirements of all types of businesses (incl. small and medium size Enterprises (SMEs)), payment factories (shared service centre), treasury centres and financial institutions. - The Implementation Guideline includes as a compliant subset the recommended core (Yellow elements) B2C Status Report from EPC. Danish - Country specific remarks are noted in the Message Definition. - Danish comments are marked within section Message Items Description. - B2C Payment Status Report test files with data (XML) with examples of national payment types. Security Several security requirements are important in the electronic exchange of messages and also in the exchange of Payment Status Reports. The security requirements for safe exchange of messages should cover the following (high level): - Ensure that no messages disappear in transport - Ensure that no messages are send more that once - Ensure that message content is not manipulated in transport (integrity) - Ensure that the sender is in fact the real sender (authentication) - Ensure the existence of a certain message to both sender and receiver (nonrepudiation) - Ensure that a message is not read by others than the sender and the receiver (confidentiality) The security requirements will not be further described in this MIG. The security requirements must be bilaterally agreed between bank and customer and be in line with the respective national requirements. Page 6 of 66

7 PART II Message: CustomerPaymentStatusReportV03 (pain ) Scope The CustomerPaymentStatusReport message is sent by an instructed agent to the previous party in the payment chain. It is used to inform this party about the positive or negative status of an instruction (either single or file). It is also used to report on a pending instruction. Usage The CustomerPaymentStatusReport message can contain: a group status a payment information status a transaction status a combination of a group status, payment information status and a transaction status The CustomerPaymentStatusReport message is exchanged between an agent and a non-financial institution customer to provide status information on instructions previously sent. Its will always be governed by a bilateral agreement between the agent and the non-financial institution customer. The CustomerPaymentStatusReport message can be used to provide information about the status (e.g. rejection, acceptance) of the initiation of a credit transfer, a direct debit, as well as on the initiation of other customer instructions (e.g. PaymentCancellationRequest). The CustomerPaymentStatusReport message refers to the original instruction(s) by means of references only or by means of references and a set of elements from the original instruction. The CustomerPaymentStatusReport message can be used in domestic and crossborder scenarios. The CustomerPaymentStatusReport message exchanged between agents and nonfinancial institution customers is identified in the schema as follows: urn:iso:std:iso:20022:tech:xsd:pain Page 7 of 66

8 Main Characteristics The CustomerPaymentStatusReport message has the following main characteristics: Identification of customer parties The CustomerPaymentStatusReport message caters for the identification of customer parties on the debit side only. The Debtor and the InitiatingParty can be identified. Outline The CustomerPaymentStatusReport message is composed of 3 building blocks: Group Header This building block is mandatory and present once. It contains elements such as MessageIdentification, CreationDateAndTime. Original Group Information and Status This building block is mandatory and present once. It contains elements such as OriginalMessageIdentification, OriginalMessageNameIdentification, GroupStatus. Original Payment Information and Status This building block is optional and repetitive. It contains elements referencing the original instruction (e.g. OriginalPaymentInformationIdentification), elements relating to the CustomerPaymentStatusReport (e.g. StatusReasonInformation). Transaction Information and Status This building block is optional and repetitive. It contains elements referencing the original instruction (e.g. OriginalEndToEndIdentification), elements relating to the CustomerPaymentStatusReport (e.g. StatusReasonInformation). The TransactionInformationAndStatus block may also transport a set of elements from the original instruction. Payment Status Report Group Header [1..1] Original Group Information and Status [1..1] Original Payment Information and Status[0..n] Transaction Information and Status [0..n] Original Transaction Reference [0..1] Page 8 of 66

9 Rules: GroupStatusAcceptedRule (R1) If OriginalGroupInformationAndStatus/GroupStatus is present and is equal to ACTC, ACCP, ACSP, ACSC or ACWC, then OriginalPaymentInformationAnd Status/PaymentInformationStatus must be different from RJCT. GroupStatusPendingRule (R2) If OriginalGroupInformationAndStatus/GroupStatus is present and is equal to PDNG, then OriginalPaymentInformationAndStatus/PaymentInformationStatus must be different from RJCT. GroupStatusRejectedRule (R3) If OriginalGroupInformationAndStatus/GroupStatus is present and is equal to RJCT, then OriginalPaymentInformationAndStatus/PaymentInformationStatus, if present, must be equal to RJCT. GroupStatusReceivedRule (R4) If OriginalGroupInformationAndStatus/GroupStatus is present and is equal to RCVD, then OriginalPaymentInformationAndStatus/PaymentInformationStatus is not allowed. StatusReasonInformationRule (R5) If GroupStatus is present and is different from RJCT or PDNG then StatusReason Information/AdditionalInformation must be absent. StatusReasonRule (R6) If Reason/Code is equal to NARR, then AddititionalInformation must be present. PaymentInformationStatusAcceptedRule (R7) If OriginalPaymentInformationAndStatus/PaymentInformationStatus is present and is equal to ACTC, ACCP, ACSP, ACSC or ACWC, then TransactionInformationAnd Status/TransactionStatus must be different from RJCT. PaymentInformationStatusPendingRule (R8) If OriginalPaymentInformationAndStatus/PaymentInformationStatus is present and is equal to RJCT, then TransactionInformationAndStatus/TransactionStatus, if present, must be equal to RJCT. PaymentInformationStatusRejectedRule (R9) If OriginalPaymentInformationAndStatus/PaymentInformationStatus is present and is equal to RJCT, then TransactionInformationAndStatus/TransactionStatus, if present, must be equal to RJCT. PaymentInformationStatusReceivedRule (R10) If OriginalPaymentInformationAndStatus/PaymentInformationStatus is present and is equal to RCVD, then TransactionInformationAndStatus/TransactionStatus is not allowed. Page 9 of 66

10 ThirdReimbursementAgentRule (R11) If ThirdReimbursementAgent is present, then InstructingReimbursementAgent and InstructedReimbursementAgent must both be present. SettlementMethodAgentRule (R12) If SettlementMethod is equal to INDA or INGA, then ReimbursementAgent(s) and ClearingSystem are not allowed. SettlementMethodCoverRule (R13) If SettlementMethod is equal to COVE, then SettlementAccount and ClearingSystem are not allowed. SettlementMethodCoverAgentRule (R14) If SettlementMethod is equal to COVE, then InstructedReimbursementAgent or InstructingReimbursementAgent must be present. SettlementMethodClearingRule (R15) If SettlementMethod is equal to CLRG, then SettlementAccount and Reimbursement Agent(s) are not allowed. InstructingReimbursementAgentAccountRule (R16) If InstructingReimbursementAgentAccount is present, then Instructing ReimbursementAgent must be present. InstructedReimbursementAgentAccountRule (R17) If InstructedReimbursementAgentAccount is present, then InstructedReimbursement Agent must be present. ThirdReimbursementAgentAccountRule (R18) If ThirdReimbursementAgentAccount is present, then ThirdReimbursementAgent must be present. AmendmentIndicatorTrueRule (R19) If AmendmentIndicator is true, then AmendementInformationDetails must be present. AmendmentIndicatorFalseRule (R20) If AmendmentIndicator is false, then AmendmentInformationDetails is not allowed. Note: Rules applying to specific message components or message elements are included in the description of the relevant message component or message element. The use of the CustomerPaymentStatusReport message has the following limitations: The CustomerPaymentStatusReport message is exchanged between an agent and a non-financial institution customer to provide status information on instructions previously sent. Its will always be governed by a bilateral agreement between the agent and the non-financial institution customer. Page 10 of 66

11 If an OriginalPaymentInformationIdentification and an OriginalEndToEnd Identification are found in a CustomerPaymentStatusReport message (OriginalPayment InformationAndStatus) then only the OriginalEndToEndIdentification will be reported on. The OriginalPaymentInformationIdentification will be ignored. The set of key elements of the original message (CustomerCreditTransfer or DirectDebitInitiation) in Original TransactionReference is NOT used. Elements of the original CustomerCreditTransfer or DirectDebitInitiation is NOT sent back to the Initiating Party (Debtor when CCT and Creditor when DDI). A CustomerPaymentStatusReport message may be triggered by a CustomerCreditTransferInitiation or by a DirectDebitInitiation. Group Status When the group is Rejected (RJCT - OriginalMessageIdentification), the TransactionInformationAndStatus block is not used. Group Status specifies the status of a transaction, in an optional coded form. If a status is given in coded form, then one of following values must be used: Code Name Definition ACCP AcceptedCustomerProfile Preceding check of technical validation was successful. Customer profile check was also successful ACSP AcceptedSettlementInProcess All preceding checks such as technical validation and customer profile were successful and therefore the payment initiation has been accepted for execution. ACTC AcceptedTechnicalValidation Authentication and syntactical and semantical validation are successful ACWC AcceptedWithChange Instruction is accepted but a change will be made, such as date or remittance not sent PART PartiallyAccepted A number of transactions have been accepted, whereas another number of transactions have not yet achieved 'accepted' status PDNG Pending Payment initiation or individual transaction included in the payment initiation is pending. Further checks and status update will be performed RJCT Rejected Payment initiation or individual transaction included in the payment initiation has been rejected Original Payment Information and Status Page 11 of 66

12 If OriginalPaymentInformationAndStatus/PaymentInformationStatus is present and is equal to RJCT, then TransactionInformationAndStatus/TransactionStatus is not used. Payment Information Status Required if reporting on a payment level or combined payment and transaction levels: Code Name Definition ACCP AcceptedCustomerProfile Preceding check of technical validation was successful. Customer profile check was also successful ACSP AcceptedSettlementInProcess All preceding checks such as technical validation and customer profile were successful and therefore the payment initiation has been accepted for execution ACWC AcceptedWithChange Instruction is accepted but a change will be made, such as date or remittance not sent PART PartiallyAccepted A number of transactions have been accepted, whereas another number of transactions have not yet achieved 'accepted' status PDNG Pending Payment initiation or individual transaction included in the payment initiation is pending. Further checks and status update will be performed RJCT Rejected Payment initiation or individual transaction included in the payment initiation has been rejected Transaction Information Status If TransactionInformationAndStatus/StatusReasonInformation is used, then OriginalGroupInformationAndStatus/StatusReasonInformation is not used. Original Transaction Reference Set of key elements of the original Customer Credit Transfer being referred to in the OriginalTransaction Reference. Transaction Status Specifies the status of a transaction, in an optional coded form. If a status is given in coded form, then one of following values must be used: Code Name Definition ACCP AcceptedCustomerProfile Preceding check of technical validation was successful. Page 12 of 66

13 Customer profile check was also successful ACSP AcceptedSettlementInProcess All preceding checks such as technical validation and customer profile were successful and therefore the payment initiation has been accepted for execution ACWC AcceptedWithChange Instruction is accepted but a change will be made, such as date or remittance not sent PDNG Pending Payment initiation or individual transaction included in the payment initiation is pending. Further checks and status update will be performed RJCT Rejected Payment initiation or individual transaction included in the payment initiation has been rejected Status Reason Specifies the reason for the status as an optional code or proprietary (Max35Text). If a status is requested in coded form, then one of following values must be used: ( reasons marked with yellow background. Codes not used in the countries are marked with red text. Codes marked with dark yellow are in the process of being submitted through ISO as External Codes. Codes with dark red on the right hand side are supported by Nets for Status on Direct Debit Initiation) Code Name Definition AC01 IncorrectAccountNumber Format of the account number specified is not correct AC02 InvalidDebtorAccountNumber Debtor account number invalid or missing AC03 InvalidCreditorAccountNumber Creditor account number invalid or missing AC04 ClosedAccountNumber Account number specified has been closed on the Receiver's books AC05 ClosedDebtorAccountNumber Debtor account number closed AC06 BlockedAccount Account specified is blocked, prohibiting posting of ransactions against it AC07 ClosedCreditorAccountNumber Creditor account number closed AC08 InvalidBranchCode Branch code is invalid or missing AC09 InvalidAccountCurrency Account currency is invalid or missing AC10 InvalidDebtorAccountCurrency Debtor account currency is invalid or missing AC11 InvalidCreditorAccountCurrency Creditor account currency is invalid or missing AC12 InvalidAccountType Account type missing or invalid Page 13 of 66

14 AC13 InvalidDebtorAccountType Debtor account type missing or invalid AC14 InvalidCreditorAccountType Creditor account type missing or invalid AG01 TransactionForbidden Transaction forbidden on this type of account (formerly NoAgreement) AG02 InvalidBankOperationCode Bank Operation code specified in the message is not valid for receiver AG03 TransactionNotSupported Transaction type not supported/authorized on this account AG04 InvalidAgentCountry Agent country code is missing or invalid AG05 InvalidDebtorAgentCountry Debtor agent country code is missing or invalid AG06 InvalidCreditorAgentCountry Creditor agent country code is missing or invalid AG07 UnsuccesfulDirectDebit Debtor account cannot be debited for a generic reason AG08 InvalidAccessRights Transaction failed due to invalid or missing user or access right AM01 ZeroAmount Specified message amount is equal to zero AM02 NotAllowedAmount Specified transaction/message amount is greater than allowed maximum AM03 NotAllowedCurrency Specified message amount is in an non processable currency outside of existing agreement AM04 InsufficientFunds Amount of funds available to cover specified message amount is insufficient AM05 Duplication This message appears to have been duplicated AM06 TooLowAmount Specified transaction amount is less than agreed minimum AM07 BlockedAmount Amount specified in message has been blocked by regulatory authorities AM09 WrongAmount Amount received is not the amount agreed or expected AM10 InvalidControlSum Sum of instructed amounts does not equal the control sum AM11 InvalidTransactionCurrency Transaction currency is invalid or missing AM12 InvalidAmount Amount is invalid or missing AM13 AmountExceedsClearingSystemLimit Transaction amount exceeds Page 14 of 66

15 limits set by clearing system AM14 AmountExceedsAgreedLimit Transaction amount exceeds limits agreed between bank and client AM15 AmountBelowClearingSystemMinimum Transaction amount below minimum set by clearing system AM16 InvalidGroupControlSum Control Sum at the Group level is invalid AM17 InvalidPaymentInfoControlSum Control Sum at the Payment Information level is invalid AM18 InvalidNumberOfTransactions Number of transactions is invalid or missing AM19 InvalidGroupNumberOfTransactions Number of transactions at the Group level is invalid or missing AM20 InvalidPaymentInfoNumberOfTransactions Number of transactions at the Payment Information level is invalid BE01 InconsistentWithEndCustomer Identification of end customer is not consistent with associated account number. (formerly CreditorConsistency) BE04 MissingCreditorAddress Specification of creditor's address, which is required for payment, is missing/not correct (formerly IncorrectCreditorAddress) BE05 UnrecognisedInitiatingParty Party who initiated the message is not recognised by the end customer BE06 UnknownEndCustomer End customer specified is not known at associated Sort/National Bank Code or does no longer exist in the books BE07 MissingDebtorAddress Specification of debtor's address, which is required for payment, is missing/not correct BE08 MissingDebtorName Debtor name is missing BE09 InvalidCountry Country code is missing or Invalid BE10 InvalidDebtorCountry Debtor country code is missing or Invalid BE11 InvalidCreditorCountry Creditor country code is missing or Invalid BE12 InvalidCountryOfResidence Country code of residence is missing or Invalid BE13 InvalidDebtorCountryOfResidence Country code of debtor's residence is missing or Invalid BE14 InvalidCreditorCountryOfResidence Country code of creditor's residence is missing or Invalid Page 15 of 66

16 BE15 InvalidIdentificationCode Identification code missing or invalid BE16 InvalidDebtorIdentificationCode Debtor or Ultimate Debtor identification code missing or invalid Page 16 of 66

17 BE17 InvalidCreditorIdentificationCode Creditor or Ultimate Creditor identification code missing or invalid BE18 InvalidContactDetails Contact details missing or invalid BE19 InvalidChargeBearerCode Charge bearer code for transaction type is invalid BE20 InvalidNameLength Name length exceeds local rules for payment type. BE21 MissingName Name missing or invalid BE22 MissingCreditorName Creditor name is missing CURR IncorrectCurrency Currency of the payment is incorrect DS0A DataSignRequested Data signature is required. DS0B UnknownDataSignFormat Data signature for the format is not available or invalid. DS0C SignerCertificateRevoked DS0D SignerCertificateNotValid The signer certificate is revoked. The signer certificate is not valid (revoked or not active). DS0E IncorrectSignerCertificate The signer certificate is not present. DS0F SignerCertificationAuthoritySignerNotValid The authority of the signer certification sending the certificate is unknown. DS0G NotAllowedPayment DS0H NotAllowedAccount Signer is not allowed to sign this operation type. Signer is not allowed to sign for this account. DS0K NotAllowedNumberOfTransaction The number of transaction is over the number allowed for this signer. DS10 Signer1CertificateRevoked The certificate is revoked for the first signer. DS11 Signer1CertificateNotValid The certificate is not valid (revoked or not active) for the first signer. DS12 IncorrectSigner1Certificate The certificate is not present for the first signer. DS13 SignerCertificationAuthoritySigner1NotValid The authority of signer certification sending the certificate is unknown for the first signer. DS20 Signer2CertificateRevoked The certificate is revoked for the second signer. DS21 Signer2CertificateNotValid The certificate is not valid (revoked or not active) for the second signer. DS22 IncorrectSigner2Certificate The certificate is not present for the second signer. Page 17 of 66

18 DS23 SignerCertificationAuthoritySigner2NotValid The authority of signer certification sending the certificate is unknown for the second signer. DT01 InvalidDate Invalid date (eg, wrong settlement date) DT02 InvalidCreationDate Invalid creation date and time in Group Header (eg, historic date) DT03 InvalidNonProcessingDate Invalid non bank processing date (eg, weekend or local public holiday) DT04 FutureDateNotSupported Future date not supported DT05 InvalidCutOffDate Associated message, payment information block or transaction was received after agreed processing cut-off date, i.e., date in the past. DT06 ExecutionDateChanged Execution Date has been modified in order for transaction to be processed DUPL DuplicatePayment Payment is a duplicate of another payment DU01 DuplicateMessageID Message Identification is not unique. DU02 DuplicatePaymentInformationID Payment Information Block is not unique. DU03 DuplicateTransaction Transaction is not unique. DU04 DuplicateEndToEndID End To End ID is not unique. DU05 DuplicateInstructionID Instruction ID is not unique. ED01 CorrespondentBankNotPossible Correspondent bank not possible ED03 BalanceInfoRequested Balance of payments complementary info is requested ED05 SettlementFailed Settlement of the transaction has failed FF01 InvalidFileFormat Operation/transaction code incorrect, invalid file format FF02 SyntaxError Syntax error reason is provided as narrative information in the additional reason information. FF03 InvalidPaymentTypeInformation Payment Type Information is missing or invalid FF04 InvalidServiceLevelCode Service Level code is missing or invalid FF05 InvalidLocalInstrumentCode Local Instrument code is missing or invalid FF06 InvalidCategoryPurposeCode Category Purpose code is missing or invalid FF07 InvalidPurpose Purpose is missing or invalid FF08 InvalidEndToEndId End to End Id missing or invalid Page 18 of 66

19 FF09 InvalidChequeNumber Cheque number missing or invalid FF10 BankSystemProcessingError File or transaction cannot be processed due to technical issues at the bank side MD01 NoMandate MD02 MissingMandatoryInformationInMandate MD03 InvalidFileFormatForOtherReason ThanGroupingIndicator MD04 InvalidFileFormatForGroupingIndicator Mandate is cancelled or invalid Mandate related information data required by the scheme is missing File format incomplete or invalid File format incorrect in terms of grouping indicator MD05 CollectionNotDue Creditor or creditor's agent should not have collected the direct debit MD06 RefundRequestByEndCustomer Return of funds requested by end customer MD07 EndCustomerDeceased End customer is deceased MS02 NotSpecifiedReasonCustomerGenerated Reason has not been specified by end customer MS03 NotSpecifiedReasonAgentGenerated Reason has not been specified by agent NARR Narrative Reason is provided as narrative information in the additional reason information* RC01 BankIdentifierIncorrect Bank identifier code specified in the message has an incorrect format (formerly IncorrectFormatForRoutingCode) RC02 InvalidBankIdentifier Bank identifier is invalid or missing RC03 InvalidDebtorBankIdentifier Debtor bank identifier is invalid or missing RC04 InvalidCreditorBankIdentifier Creditor bank identifier is invalid or missing RC05 InvalidBICIdentifier BIC identifier is invalid or missing RC06 InvalidDebtorBICIdentifier Debtor BIC identifier is invalid or missing RC07 InvalidCreditorBICIdentifier Creditor BIC identifier is invalid or missing RC08 InvalidClearingSystemMemberIdentifier ClearingSystemMemberidentifier is invalid or missing RC09 InvalidDebtorClearingSystemMemberIdentifier Debtor ClearingSystemMember identifier is invalid or missing RC10 InvalidCreditorClearingSystemMemberIdentifier Creditor ClearingSystemMember identifier is invalid or missing RC11 InvalidIntermediaryAgent Intermediary Agent is invalid or missing Page 19 of 66

20 RC12 MissingCreditorSchemeId Creditor Scheme Id is invalid or missing RF01 NotUniqueTransactionReference Transaction reference is not unique within the message RR01 SpecificationOfTheDebtorsAccountOr RegulatoryReason UniqueIdentificationNeededForReasonsO fregulatoryrequirementsisinsufficientor Missing RR02 SpecificationOfTheDebtorsNameAndOr RegulatoryReason AddressNeededForRegulatoryRequireme ntsisinsufficientor Missing RR03 SpecificationOfTheCreditorsNameAndOr RegulatoryReason AddressNeededForRegulatoryRequireme ntsisinsufficientor Missing RR04 RegulatoryReason RegulatoryReason RR05 RegulatoryInformationInvalid Regulatory or Central Bank Reporting information missing, incomplete or invalid. RR06 TaxInformationInvalid Tax information missing, incomplete or invalid. RR07 RemittanceInformationInvalid Remittance information structure does not comply with rules for payment type. RR08 RemittanceInformationTruncated Remittance information truncated to comply with rules for payment type. RR09 InvalidStructuredCreditorReference Structured creditor reference invalid or missing. RR10 InvalidCharacterSet Character set supplied not valid for the country and payment type. RR11 InvalidDebtorAgentServiceID Invalid or missing identification of a bank proprietary service. RR12 InvalidPartyID Invalid or missing identification required within a particular country or payment type. SL01 Specific Service offered by Debtor Agent Due to specific service offered by the Debtor Agent SL02 Specific Service offered by Creditor Agent Due to specific service offered by the Creditor Agent TM01 CutOffTime (Invalid) Associated message was received after agreed processing cut-off time (payment information block or transaction) * Additional reason information has a multiplicity of [0..n] in the ISO Message Definition Report but in the MIG [0..5] will be supported only. Page 20 of 66

21 Format Specifications - The order of the elements in the format follows the order of the elements in the schema. - The first view on the format provides a high-level view, showing the main elements and the first level of the tree structure of the message. The second view on the format provides the detailed message format. - How to read the format: Index = reference number that points to the related field description after the format XML tag = A specific name assigned to a Message Item and that will appear in the XML Schema and in XML instances that use this Message Item. Ind. Or Message item <XML Tag> Mult Type Rule 1.0 Group Header <GrpHdr> [1..1] MessageIdentification <MsgId> [1..1] Text CreationDateTime <CreDtm> [1..1] DateTime Message items = A Message Item is a composing part of a Message. It can be a Message Element (which can be compared to the fields of a traditional message or a Message Component (which can be compared to a block of information, consisting of different message elements). Each Message Item is to be completed with a type. The plus signs indicates the structural level. Message item descriptions can be found in the Message Item description section. Mult = Indication whether something is optional, mandatory and/or repetitive. Multiplicity is represented by a notation between square brackets. Examples of multiplicity: [0..1] this element can be present 0 or 1 time, i.e. it is optional and not repeatable. [0..n] this element can be present 0 time, and may be repeated any number of times. [1..1] this element is present exactly once. [1..n] this element is always present at least once, and may be repeated any number of times. A type is a generic name, covering Data Types and Message Components when they are used to define the allowed structure and/or allowed set of values of a Message Item. The type column can be compared to the Content/options column of a FIN format. If a type consists of a component, this means that the component in its own turn is composed of a next set of items. This next set of items will also be included in the message item column (except for components frequently re-used, such as party choice, that are described once in the separate Type section after the message format section.) A component can also be a choice component : this component represents a choice between different possible items (can be compared to the options A, B,D in SWIFT FIN messages to identify a party). Only one possibility can be used. The items being part of a choice component are marked with or in the message item column. If a type consists of a Data Type, this means that you are at the lowest level of the type. The data type specifies the possible values that a Message Element can have. This can be done with a format specification (e.g. a date format such as YYY-MM-DD) or via an enumeration (e.g. a list of all possible codes). In the column here, you will see the representation of the data type. A Data Type Representation is used to group similar Data Types, such as Codes, Dates, Text, etc. The 8 generic different Data type representations which can be used to complement message elements are: Identifier/Code/Text/Rate/DateTime/Amount/Quantity/Indicator. (Note: 'Quantity is not used in the payment initiation messages) The type section contains a list and description of all data types used and a description of the frequently reused components. Page 21 of 66

22 Message Structure - CustomerPaymentStatusReport General principles and explanations concerning the table containing the format and structure for Payment Status Report - elements and objects are still present and kept for information. They are clearly marked with "" in the MIG column and by grey shading in the rows. If a generic composite element is, then in some cases the underlying elements are not listed in the table. - If an element or object is not used, is present and forwarded, it is agreed in the Danish banking community, that it will not generate a rejection. It is also agreed that such elements will not be semantically recognized and handled automatically in the systems. This means that the receiving bank will not process it or at best display the information in an unstructured manor. - Elements marked as recommended for use in the CustomerPaymentStatusReport Implementation Guideline is marked with yellow background in the index column. Insofar elements are recommended for use in but not used by the Danish banking community then these elements are also marked with yellow background in the Remarks on Danish column. - Elements with red background are not to be populated according to the rulebook. - Elements with violet background are populated when reporting on Direct Debit Initiation only. - All elements and objects have maintained their presence and definitions as original stated in the ISO approved CustomerPaymentStatusReport message standard. - If there are agreements, business rules or other notes being specific to a country or more, those are described in the Remarks on Danish column. - Codes that are part of the official fixed code lists but not recognised in the MIG will be treated as having the default value described. Other codes outside the fixed list generate rejection. Page 22 of 66

23 Instruction on how to read the Message Structure table. 1. See the Color /Background (table below) Color/Background (Left or Right hand side) Yellow background (left hand side) Yellow background (right hand side) Gray text (right hand side only) Gray text White background and Black text in all collums White background (with no text in right side) Red background (left in index and right in Danish ) Violet background (left in index and right in Danish ) Meaning element element that is not supported on initiation in Denmark¹ CGI element is not used in Denmark ISO element is not used in Denmark CGI element is used in Denmark and the is specified² CGI element is used in Denmark Not to be populated according to the rulebook Populated when reporting on Direct Debit Initiation only ¹The element is not used in messages initiated in Denmarks. The element must be supported if it is received in a message from other countries. ²If an element is used in Denmark by a limited number of banks only Then the element is Bilaterally Determined. The of the element is standardised within the banks. 2. See the Presence of the element (table below) Presence notation Meaning 0-1 Optional (Element is not required) 1-1 Mandatory (Element is required) 0- Optional with unlimited repetition 1- Mandatory with unlimited repetition The combination of the Color and the Presence gives the reader the ability to identify if an element is used. The Appendix with the CustomerPaymentStatusReport examples contain important related information. Page 23 of 66

24 1.0 +GroupHeader <GrpHdr> [1..1] Component Set of characteristics shared by all individual transactions included in the message MessageIdentification <MsgId> [1..1] Max35Text CreationDateTime <CreDtTm> [1..1] ISODateTime InitiatingParty <InitgPty> [1..1] Party Identification Component +++Name <Nm> [0..1] Max140Text +++PostalAddress <PstlAdr> [0..1] Component ++++AdressType <AdrTp> [0..1] Code ++++Department <Dept> [0..1] Max70Text ++++SubDepartment <SubDept> [0..1] Max70Text Point to point reference assigned by the instructing party and sent to the next party in the chain to unambiguously identify the message. Date and time at which the (group of) status report(s) was created by the instructing party. Party that initiates the status message. Name by which a party is known and which is usually used to identify that party. identifies a specific address, as defined by postal services. Identifies the nature of the postal address Identification of a division of a large organisation or building. Identification of a sub-division of a large organisation or building. Unique for each cust. min. 3 months ++++StreetName <StrtNm> [0..1] Max70Text Name of a street or thoroughfare. ++++BuildingNumber <BldgNb> [0..1] Max16Text Number that identifies the position of a building on a street. ++++PostCode <PstCd> [0..1] Max16Text Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting of mail. ++++TownName <TwnNm> [0..1] Max35Text Name of a built-up area, with defined boundaries, and a local government. ++++CountrySubDivision <CtrySubDvsn> [0..1] Max35Text Identifies a subdivision of a country eg, state, region, country. ++++Country <Ctry> [1..1] CountryCode Nation with its own government. ++++AdressLine <AdrLine> [0..7] Max70Text identifies a specific address, as defined by postal services, that is presented in free format text. Page 24 of 66

25 +++Identification <Id> [0..1] Choice Component Unique and unambiguous way of identifying an organisation or an individual person. {Or ++++OrganisationIdentification <OrgId> [1..1] Component Unique an unambiguous way of identifying an organisation BICOrBEI <BICOrBEI> [0..1] Identifier Code allocated to organisations by the ISO 9362 Registration Authority, under an international identification scheme, as described in the latest version of the standard ISO 9362 Banking (Banking telecommunication messages, Bank Identifier Codes). Bank only +++++Other <Othr> [0..n] Component Unique identification of an organisation, as assigned by an institution, using an identification scheme Identification <Id> [1..1] Max35Text Identification assigned by an institution SchemeName <SchmeNm> [0..1] Choice Component Name of the identification scheme. {Or Code <Cd> [1..1] Code in a coded form as published in an external list. Or} Proprietary <Prtry> [1..1] Max35Text in a free text form. Page 25 of 66 For customer identification only CUST: Receiver of Status Message Issuer <Issr> [0..1] Max35Text Entity that assigns the identification ++++PrivateIdentification <PrvtId> [1..1] Component Unique and unambiguous identification of a party +++++DateAndPlaceOfBirth <DtAndPlcOfBirth [0..1] Component Date and place of birth of a person BirthDate <BirthDt> [1..1] ISODate Date on which a person is born ProvinceOfBirth <PrvcOfBirth> [0..1] Max35Text Province where a person was born CityOfBirth <CityOfBirth> [1..1] Max35Text City where a person was born CountryOfBirth <CityOfBirth> [1..1] CountryCode Country where a person was born +++++Other <Othr> [0..n] Component Unique identification of an organisation, as assigned by an institution, using an identification scheme Identification <Id> [1..1] Max35Text Unique and unambiguous identification of a person SchemeName <SchmeNm> [0..1] Choice Component Name of the identification scheme. {Or Code <Cd> [1..1] Code in a coded form as published in an external list. Or} Proprietary <Prtry> [1..1] Max35Text in a free text form Issuer <Issr> [0..1] Max35Text Entity that assigns the identification

26 +++CountryOfResidence <CtryOfRes> [0..1] CountryCode Country in which a person resides (the place of a person's home). In the case of a company, it is the country from which the affairs of that company are directed. +++ContactDetails <CtctDtls> [0..1] Component Set of elements used to indicate how to contact the party. ++++NamePrefix <NmPrfx> [0..1] Code Specifies the terms used to formally address a person. ++++Name <Nm> [0..1] Max140Text Name by which a party is known and which is usually used to identify that party. ++++PhoneNumber <PhneNb> [0..1] PhoneNumber Collection of information that identifies a phone number, as defined by telecom services. ++++MobileNumber <MobNb> [0..1] PhoneNumber Collection of information that identifies a mobile phone number, as defined by telecom services. ++++FaxNumber <FaxNb> [0..1] PhoneNumber Collection of information that identifies a FAX number, as defined by telecom services Address < Adr> [0..1] Max2048Text Address for electronic mail ( ). ++++Other <Othr> [0..1] Max35Text Contact details in an other form ForwardingAgent <FwdgAgt> [0..1] Financial Institution Identification Component +++FinancialInstitutionIdentification <FinInstnId> [1..1] Choice Component {Or ++++BIC <BIC> [1..1] BICIdentifier Or ++++ClearingSystemMemberIdentification <ClrSysMmbId> [1..1] Component Financial institution that receives the instruction from the initiating party and forwards it to the next agent in the payment chain for execution. Unique and unambiguous identifier of a financial institution, as assigned under an internationally recognised or proprietary identification scheme. Bank Identifier Code. Code allocated to financial institutions by the Registration Authority, under an international identification scheme, as described in the latest version of the standard ISO 9362 Banking (Banking telecommunication messages, Bank Identifier Codes). Unique and unambiguous identifier of a clearing system member, as assigned by the system or system administrator. Page 26 of 66

27 +++++ClearingSystemIdentification <ClrSysId> [0..1] Component Specification of a pre-agreed offering between clearing agents or the channel through which the payment instruction is processed. {Or Code <Cd> [1..1] Code Identification of a clearing system, in a coded form as published in an external list. Or} Proprietary <Prtry> [1..1] Max35Text Identification code for a clearing system, that has not yet been identified in the list of clearing systems MemberIdentification <MmbId> [1..1] Max35Text Identification of a member of a clearing system. ++++Name <Nm> [0..1] Max140Text Name by which a party is known and which is usually used to identify that party. ++++PostalAddress <PstlAdr> [0..1] Component identifies a specific address, as defined by postal services AdressType <AdrTp> [0..1] Code Identifies the nature of the postal address +++++Department <Dept> [0..1] Max70Text Identification of a division of a large organisation or building SubDepartment <SubDept> [0..1] Max70Text Identification of a sub-division of a large organisation or building StreetName <StrtNm> [0..1] Max70Text Name of a street or thoroughfare BuildingNumber <BldgNb> [0..1] Max16Text Number that identifies the position of a building on a street PostCode <PstCd> [0..1] Max16Text Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting of mail TownName <TwnNm> [0..1] Max35Text Name of a built-up area, with defined boundaries, and a local government CountrySubDivision <CtrySubDvsn> [0..1] Max35Text Identifies a subdivision of a country eg, state, region, country Country <Ctry> [1..1] CountryCode Nation with its own government AdressLine <AdrLine> [0..7] Max70Text identifies a specific address, as defined by postal services, that is presented in free format text. ++++Other <Othr> [0..n] Component Unique identification of an agent, as assigned by an institution, using an identification scheme. Page 27 of 66

28 +++++Identification <Id> [1..1] Max35Text Unique and unambiguous identification of a person +++++SchemeName <SchmeNm> [0..1] Choice Component Name of the identification scheme. {Or Code <Cd> [1..1] Code in a coded form as published in an external list. Or} Proprietary <Prtry> [1..1] Max35Text in a free text form Issuer <Issr> [0..1] Max35Text Entity that assigns the identification +++BranchIdentification <BrnchId> [0..1] Component Information identifying a specific branch of a financial institution. Usage: this component should be used in case the identification information in the financial institution component does not provide identification up to branch level. ++++Identification <Id> [0..1] Max35Text Unique and unambiguous identification of a branch of a financial institution. ++++Name <Nm> [0..1] Max140Text Name by which a party is known and which is usually used to identify that party. ++++PostalAddress <PstlAdr> [0..1] Component identifies a specific address, as defined by postal services AdressType <AdrTp> [0..1] Code Identifies the nature of the postal address +++++Department <Dept> [0..1] Max70Text Identification of a division of a large organisation or building SubDepartment <SubDept> [0..1] Max70Text Identification of a sub-division of a large organisation or building StreetName <StrtNm> [0..1] Max70Text Name of a street or thoroughfare BuildingNumber <BldgNb> [0..1] Max16Text Number that identifies the position of a building on a street PostCode <PstCd> [0..1] Max16Text Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting of mail TownName <TwnNm> [0..1] Max35Text Name of a built-up area, with defined boundaries, and a local government CountrySubDivision <CtrySubDvsn> [0..1] Max35Text Identifies a subdivision of a country eg, state, region, country Country <Ctry> [1..1] CountryCode Nation with its own government. Page 28 of 66

29 +++++AdressLine <AdrLine> [0..7] Max70Text identifies a specific address, as defined by postal services, that is presented in free format text DebtorAgent <DbtrAgt> [0..1] Financial Institution Identification Financial institution servicing an Component account for the debtor. Unique and unambiguous identifier of a financial institution, as +++FinancialInstitutionIdentification <FinInstnId> [1..1] Choice Component assigned under an internationally recognised or proprietary identification scheme. {Or ++++BIC <BIC> [1..1] BICIdentifier Bank Identifier Code. Code allocated to financial institutions by the Registration Authority, under an international identification scheme, as described in the latest version of the standard ISO 9362 Banking (Banking telecommunication messages, Bank Identifier Codes). Or ++++ClearingSystemMemberIdentification <ClrSysMmbId> [1..1] Component Unique and unambiguous identifier of a clearing system member, as assigned by the system or system administrator ClearingSystemIdentification <ClrSysId> [0..1] Component Specification of a pre-agreed offering between clearing agents or the channel through which the payment instruction is processed. {Or Code <Cd> [1..1] Code Identification of a clearing system, in a coded form as published in an external list. Or} Proprietary <Prtry> [1..1] Max35Text Identification code for a clearing system, that has not yet been identified in the list of clearing systems MemberIdentification <MmbId> [1..1] Max35Text Identification of a member of a clearing system. ++++Name <Nm> [0..1] Max140Text Name by which a party is known and which is usually used to identify that party. ++++PostalAddress <PstlAdr> [0..1] Component identifies a specific address, as defined by postal services AdressType <AdrTp> [0..1] Code Identifies the nature of the postal address +++++Department <Dept> [0..1] Max70Text Identification of a division of a large organisation or building. Page 29 of 66