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

(1)

Danish Implementation Guideline for

Common Global Implementation (CGI)

Customer Payment Status Report

– based on documentation from ISO 20022 Message

Definition Report

(2)

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 Danish CGI scope and goals

6 Danish CGI usage

6 SECURITY

6 PART II

7 Message: CustomerPaymentStatusReportV03 (pain.002.001.03)

7 MAIN CHARACTERISTICS

8 FORMAT SPECIFICATIONS

21

(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 20022 Message

Definition Report and the message CustomerPaymentStatusReport

<pain.002.001.03>.

The ISO 20022 Message Definition Report (MDR) and Message Usage Guideline

(MUG) can be downloaded from:

http://www.iso20022.org

How to read this document

The Danish CGI 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

usage 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 Danish CGI MIG? The scope and usage of the Danish CGI MIG is presented

under the section “Danish CGI 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, Danish CGI comments have been added,

presenting the Danish CGI usage of the Items within the message.

Note: The reader need to refer to the ISO 20022 CustomerPaymentStatusReport

message in order to get the complete overview of the functionality of the message.

(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 usage will

always be governed by a bilateral agreement between the agent and the

non-financial 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.

(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.

(6)

Danish CGI Message Definition

The Danish CGI 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.

Danish CGI 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 Danish CGI Implementation Guideline includes as a compliant subset the

recommended core (Yellow elements) B2C SEPA Status Report from EPC.

Danish usage

-

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

(non-repudiation)

-

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.

(7)

PART II

Message: CustomerPaymentStatusReportV03

(pain.002.001.03)

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 usage 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

cross-border scenarios.

The CustomerPaymentStatusReport message exchanged between agents and

non-financial institution customers is identified in the schema as follows:

(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

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]

Group Header [1..1]

(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.

(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 usage will always be governed by a bilateral agreement between

the agent and the non-financial institution customer.

(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

(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.

(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:

(SEPA reasons marked with yellow background. Codes not used in the Danish CGI

countries are marked with red text. Codes marked with dark yellow are in the

process of being submitted through ISO 20022 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

(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

(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

(16)

BE15

InvalidIdentificationCode

Identification code missing or

invalid

BE16

InvalidDebtorIdentificationCode

Debtor or Ultimate Debtor

identification code missing or

invalid

(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

The signer certificate is revoked.

DS0D SignerCertificateNotValid

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

Signer is not allowed to sign this

operation type.

DS0H NotAllowedAccount

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.

(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

(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

Mandate is cancelled or invalid

MD02 MissingMandatoryInformationInMandate

Mandate related information data

required by the scheme is

missing

MD03 InvalidFileFormatForOtherReason

ThanGroupingIndicator

File format incomplete or invalid

MD04 InvalidFileFormatForGroupingIndicator

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

(20)

RC12 MissingCreditorSchemeId

Creditor Scheme Id is invalid or

missing

RF01

NotUniqueTransactionReference

Transaction reference is not

unique within the message

RR01 SpecificationOfTheDebtorsAccountOr

UniqueIdentificationNeededForReasonsO

fRegulatoryRequirementsIsInsufficientOr

Missing

RegulatoryReason

RR02 SpecificationOfTheDebtorsNameAndOr

AddressNeededForRegulatoryRequireme

ntsIsInsufficientOr Missing

RegulatoryReason

RR03 SpecificationOfTheCreditorsNameAndOr

AddressNeededForRegulatoryRequireme

ntsIsInsufficientOr Missing

RegulatoryReason

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 20022

Message Definition Report but in the Danish CGI MIG [0..5] will be supported

only.

(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

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.

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.

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

re-used components.

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.

Ind. Or Message item <XML Tag> Mult Type Rule

1.0 Group Header

<GrpHdr>

[1..1]

1.1 + MessageIdentification

<MsgId>

[1..1]

Text

(22)

Message Structure - CustomerPaymentStatusReport

General principles and explanations concerning the table containing the

format and structure for Payment Status Report

-

Not used elements and objects are still present and kept for information. They are clearly marked with "Not used" in the

Danish CGI MIG column and by grey shading in the rows. If a generic composite element is “Not used”, 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 SEPA CustomerPaymentStatusReport Implementation Guideline is

marked with yellow background in the index column. Insofar elements are recommended for use in SEPA but not used by

the Danish banking community then these elements are also marked with yellow background in the Remarks on Danish

usage column.

-

Elements with red background are not to be populated according to the SEPA rulebook.

-

Elements with violet background are populated when reporting on SEPA Direct Debit Initiation only.

-

All elements and objects have maintained their presence and definitions as original stated in the ISO 20022 approved

CustomerPaymentStatusReport message standard.

-

If there are agreements, business rules or other usage notes being specific to a country or more, those are described in the

Remarks on Danish usage column.

-

Codes that are part of the official fixed code lists but not recognised in the Danish CGI MIG will be treated as having the

default value described. Other codes outside the fixed list generate rejection.

(23)

Instruction on how to read the Message Structure table.

1. See the Color /Background (table below)

Color/Background (Left or Right hand side)

Meaning

Yellow background (left hand side)

SEPA element

Yellow background (right hand side)

SEPA element that is not supported on initiation in Denmark¹

Gray text (right hand side only)

CGI element is not used in Denmark

Gray text

ISO element is not used in Denmark

White background and Black text in all collums

CGI element is used in Denmark and the usage is specified²

White background (with no text in right side)

CGI element is used in Denmark

Red background (left in index and right in Danish usage)

Not to be populated according to the SEPA rulebook

Violet background (left in index and right in Danish usage)

Populated when reporting on SEPA Direct Debit Initiation only

¹The SEPA element is not used in messages initiated in Denmarks. The element must be supported if it is received in a message

from other SEPA countries.

²If an element is used in Denmark by a limited number of banks only – Then the element is Bilaterally Determined. The usage 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 Danish CGI CustomerPaymentStatusReport examples contain important related information.

(24)

Ind.

Or

Message Item

<XML Tag>

Mult.

Type

Definition

Remarks on

Danish CGI

usage

1.0 +GroupHeader <GrpHdr> [1..1] Component

Set of characteristics shared by all individual transactions included in the message.

1.1 ++MessageIdentification <MsgId> [1..1] Max35Text

Point to point reference assigned by the instructing party and sent to the next party in the chain to unambiguously identify the message.

Unique for each cust. min. 3 months

1.2 ++CreationDateTime <CreDtTm> [1..1] ISODateTime

Date and time at which the (group of) status report(s) was created by the instructing party.

1.3 + ++InitiatingParty <InitgPty> [1..1] Party Identification Component Party that initiates the status message.

+++Name <Nm> [0..1] Max140Text

Name by which a party is known and which is usually used to identify that party.

Not used

+++PostalAddress <PstlAdr> [0..1] Component

Information that locates and identifies a specific address, as defined by postal services.

Not used

++++AdressType <AdrTp> [0..1] Code Identifies the nature of the postal_address Not used

++++Department <Dept> [0..1] Max70Text Identification of a division of a large

organisation or building. Not used

++++SubDepartment <SubDept> [0..1] Max70Text Identification of a sub-division of a

large organisation or building. Not used

++++StreetName <StrtNm> [0..1] Max70Text Name of a street or thoroughfare. Not used

++++BuildingNumber <BldgNb> [0..1] Max16Text Number that identifies the position

of a building on a street. Not used

++++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.

Not used

++++TownName <TwnNm> [0..1] Max35Text

Name of a built-up area, with defined boundaries, and a local government.

Not used

++++CountrySubDivision <CtrySubDvsn> [0..1] Max35Text Identifies a subdivision of a country

eg, state, region, country. Not used

++++Country <Ctry> [1..1] CountryCode Nation with its own government. Not used

++++AdressLine <AdrLine> [0..7] Max70Text

Information that locates and identifies a specific address, as defined by postal services, that is presented in free format text.

(25)

Ind.

Or

Message Item

<XML Tag>

Mult.

Type

Definition

Remarks on

Danish CGI

usage

+++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.

For customer identification only ++++++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

Name of the identification scheme, in a coded form as published in an external list.

CUST: Receiver of Status Message

Or} +++++++Proprietary <Prtry> [1..1] Max35Text Name of the identification scheme,

in a free text form. Not used

++++++Issuer <Issr> [0..1] Max35Text Entity that assigns the identification Not used

++++PrivateIdentification <PrvtId> [1..1] Component Unique and unambiguous

identification of a party Not used

+++++DateAndPlaceOfBirth <DtAndPlcOfBirth [0..1] Component Date and place of birth of a person Not used

++++++BirthDate <BirthDt> [1..1] ISODate Date on which a person is born Not used

++++++ProvinceOfBirth <PrvcOfBirth> [0..1] Max35Text Province where a person was born Not used

++++++CityOfBirth <CityOfBirth> [1..1] Max35Text City where a person was born Not used

++++++CountryOfBirth <CityOfBirth> [1..1] CountryCode Country where a person was born Not used

+++++Other <Othr> [0..n] Component

Unique identification of an organisation, as assigned by an institution, using an identification scheme.

Not used

++++++Identification <Id> [1..1] Max35Text Unique and unambiguous

identification of a person Not used

++++++SchemeName <SchmeNm> [0..1] Choice Component Name of the identification scheme. Not used

{Or +++++++Code <Cd> [1..1] Code

Not used

Or} +++++++Proprietary <Prtry> [1..1] Max35Text Name of the identification scheme,

(26)

Ind.

Or

Message Item

<XML Tag>

Mult.

Type

Definition

Remarks on

Danish CGI

usage

+++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.

Not used

+++ContactDetails <CtctDtls> [0..1] Component Set of elements used to indicate

how to contact the party. Not used

++++NamePrefix <NmPrfx> [0..1] Code Specifies the terms used to formally_{address a person.} Not used

++++Name <Nm> [0..1] Max140Text

Not used

++++PhoneNumber <PhneNb> [0..1] PhoneNumber

Collection of information that identifies a phone number, as defined by telecom services.

Not used

++++MobileNumber <MobNb> [0..1] PhoneNumber

Collection of information that identifies a mobile phone number, as defined by telecom services.

Not used

++++FaxNumber <FaxNb> [0..1] PhoneNumber

Collection of information that identifies a FAX number, as defined by telecom services.

Not used

++++EmailAddress <EmailAdr> [0..1] Max2048Text Address for electronic mail (e-mail). Not used

++++Other <Othr> [0..1] Max35Text Contact details in an other form. Not used

1.4+ ++ForwardingAgent <FwdgAgt> [0..1] Financial Institution Identification

Component

Financial institution that receives the instruction from the initiating party and forwards it to the next agent in the payment chain for execution.

Not used

+++FinancialInstitutionIdentification <FinInstnId> [1..1] Choice Component

Unique and unambiguous identifier of a financial institution, as assigned under an internationally recognised or proprietary identification scheme.

Not used

{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).

Not used

Or ++++ClearingSystemMemberIdentification <ClrSysMmbId> [1..1] Component

Unique and unambiguous identifier of a clearing system member, as assigned by the system or system administrator.

(27)

Ind.

Or

Message Item

<XML Tag>

Mult.

Type

Definition

Remarks on

Danish CGI

usage

+++++ClearingSystemIdentification <ClrSysId> [0..1] Component

Specification of a pre-agreed offering between clearing agents or the channel through which the payment instruction is processed.

Not used

{Or ++++++Code <Cd> [1..1] Code

Identification of a clearing system, in a coded form as published in an external list.

Not used

Or} ++++++Proprietary <Prtry> [1..1] Max35Text

Identification code for a clearing system, that has not yet been identified in the list of clearing systems.

Not used

+++++MemberIdentification <MmbId> [1..1] Max35Text Identification of a member of a

clearing system. Not used

Not used

++++PostalAddress <PstlAdr> [0..1] Component

Not used

+++++AdressType <AdrTp> [0..1] Code Identifies the nature of the postal

address Not used

+++++Department <Dept> [0..1] Max70Text Identification of a division of a large

+++++SubDepartment <SubDept> [0..1] Max70Text Identification of a sub-division of a

+++++StreetName <StrtNm> [0..1] Max70Text Name of a street or thoroughfare. Not used

+++++BuildingNumber <BldgNb> [0..1] Max16Text Number that identifies the position

+++++PostCode <PstCd> [0..1] Max16Text

Not used

+++++TownName <TwnNm> [0..1] Max35Text

Not used

+++++CountrySubDivision <CtrySubDvsn> [0..1] Max35Text Identifies a subdivision of a country

+++++Country <Ctry> [1..1] CountryCode Nation with its own government. Not used

+++++AdressLine <AdrLine> [0..7] Max70Text

Not used

++++Other <Othr> [0..n] Component

Unique identification of an agent, as assigned by an institution, using an identification scheme.

(28)

Ind.

Or

Message Item

<XML Tag>

Mult.

Type

Definition

Remarks on

Danish CGI

usage

+++++Identification <Id> [1..1] Max35Text Unique and unambiguous

+++++SchemeName <SchmeNm> [0..1] Choice Component Name of the identification scheme. Not used

{Or ++++++Code <Cd> [1..1] Code

Not used

Or} ++++++Proprietary <Prtry> [1..1] Max35Text Name of the identification scheme,

+++++Issuer <Issr> [0..1] Max35Text Entity that assigns the identification Not used

+++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.

Not used

++++Identification <Id> [0..1] Max35Text

Unique and unambiguous identification of a branch of a financial institution.

Not used

address Not used

Not used

(29)

Ind.

Or

Message Item

<XML Tag>

Mult.

Type

Definition

Remarks on

Danish CGI

usage

Not used

1.5 + ++DebtorAgent <DbtrAgt> [0..1] Financial Institution Identification Component

Financial institution servicing an

account for the debtor. SEPA

SEPA

Not used

+++++ClearingSystemIdentification <ClrSysId> [0..1] Component

Specification of a pre-agreed offering between clearing agents or the channel through which the payment instruction is processed.

Not used

{Or ++++++Code <Cd> [1..1] Code

Identification of a clearing system, in a coded form as published in an external list.

Not used

Or} ++++++Proprietary <Prtry> [1..1] Max35Text

Identification code for a clearing system, that has not yet been identified in the list of clearing systems.

Not used

+++++MemberIdentification <MmbId> [1..1] Max35Text Identification of a member of a

clearing system. Not used

Not used

address Not used

(30)

Ind.

Or

Message Item

<XML Tag>

Mult.

Type

Definition

Remarks on

Danish CGI

usage

Not used

++++Other <Othr> [0..n] Component

Unique identification of an agent, as assigned by an institution, using an identification scheme.

Not used

+++++Identification <Id> [1..1] Max35Text Unique and unambiguous

+++++SchemeName <SchmeNm> [0..1] Choice Component Name of the identification scheme. Not used

{Or ++++++Code <Cd> [1..1] Code

Not used

Or} ++++++Proprietary <Prtry> [1..1] Max35Text Name of the identification scheme,

+++++Issuer <Issr> [0..1] Max35Text Entity that assigns the identification Not used

+++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.

Not used

++++Identification <Id> [0..1] Max35Text

Unique and unambiguous identification of a branch of a financial institution.

Not used

(31)

Ind.

Or

Message Item

<XML Tag>

Mult.

Type

Definition

Remarks on

Danish CGI

usage

Not used

address Not used

Not used

1.6 + ++CreditorAgent <CdtrAgt> [0..1] Financial Instititution Identification Component

Financial institution servicing an

account for the creditor. SEPA

SEPA

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