1. No category

BSK implementeringsguide
ISO 20022
PAIN 002.001.03
Customer Payment Status
Report
Bankenes felles implementasjonsguide
Basert på Common Global Implementation
“CGI Guide for ISO 20022
CustomerPaymentStatusReport (CPSR)”
of July 2010
januar 2012
Innhold
Endringskatalog
Dato
15.01.2012
Ver
1.0
Utført av
Morten Holter
endringer
Første versjon.
Side
Innhold
1. Innledning
1.1 Funksjonell beskrivelse
1.1.1 Omfang av meldingssettet
2. Eksempler på bruk av CustomerPaymentStatusReport
2.1 Kvittering på mottatt betalingsoppdrag hvor oppdraget kan gjennomføres
2.2 Kvittering på mottatt betalingsoppdrag hvor enkelte av transaksjonene avvises
2.3 Statusrapport på innsendt transaksjon som avvises i gjennomføringsøyeblikket
3. Melding Pain.002.001.03 – CustomerPaymentStatusReport V03 Teknisk beskrivelse
3.1 Bruk av melding
3.2 Meldingsoppbygging
4 Struktur
4.1 Forklaring til tabellene
4.1.2 Formatspesifikasjon
5. Message Functionality
5.0.1 Group Header Functionality
5.0.2 Original Group Information And Status Functionality
5.0.3 Original Payment Information And Status Functionality
5.1 Functional Structure
5.1.1 Group Header
5.1.2 Original Group Information And Status
5.1.3 Original Payment Information And Status
BSK Bank IG ver 1 av Pain.002.001.03 CustomerPaymentStatusReport 201201
3
4
4
6
6
7
8
9
9
9
10
10
10
12
12
13
13
14
16
17
18
Side 2 av 19
1. Introduksjon
1. Innledning
Implementasjonsguiden er utarbeidet i regi av BSK.
Denne implementasjonsguiden for Customer Payment Status Report er basert på
“ISO 20022 Message Definition Report” (MDR) og Common Global Implementation “CGI Guide for ISO
20022 Customer Payment Status Report” (CPSR) of July 2010
Implementasjonsguiden beskriver hvordan XML ISO 20022 format skal benyttes for formidling av
statusrapport fra finansinstitusjoner til kunder på mottatte betalingsoppdrag, og definerer hvilke
informasjonselementer som skal være med i en statusrapport, og som bankene kan formidle tilbake til
innsender av betalingsoppdrag.
Implementasjonsguiden kan også være til nytte i planlegging og oppbygging av ERP - systemer som vil
benytte xml-formater for utveksling av informasjon.
ISO 20022 Message Definition Report (MDR) og Message Usage Guideline
(MUG) kan lastes ned fra: http://www.iso20022.org
Common Global Implementation initiative (ISO 20022 – CGI Initiative) is a SWIFT comunity dedicated to the
Common Global ImplementationInitiative (CGI). Main objective of the Group is to define one common
globalimplementation standard for ISO 20022 messages in the Corporate-to-Bank space.
Målgruppe
Customer Payment Status Report inneholder informasjon fra finansinstitusjon (instructed agent), beregnet
på innsender av betalingsoppdrag. Rapporten skal gi oppdragsgiver informasjon om hvorvidt et mottatt
betalingsoppdrag kan gjennomføres i henhold til instruks, eller om den avvises, og i så tilfelle årsak til
avvisning. Status kan gis på enkelttransaksjonsnivå, eller refere til et innsendt oppdrag. Bruken vil alltid
være styrt av avtalen mellom kunde og finansinstitusjon.
Første del av implementasjonsguiden gir en oversikt på generelt grunnlag om bruk av CPSR-meldinger, med
fokus på funksjonalitet og omfang.
Rapporten skal nyttes av finansinstitusjoner til å kvittere tilbake til oppdragsgiver som har benyttet
CustomerCreditTransfer melding til å instruere betalers bank om å foreta en betalingsoverføring fra en
angitt konto.
Andre del er en veiledning i hvordan meldingstypen skal implementeres, og er rettet mot teknisk personell
som vil ha det som oppgave. Den er bygget opp i tabellform med detaljert beskrivelse av meldingsstruktur
og krav til meldingsinnhold, samt eventuelle tilleggs forklaringer for å tydeliggjøre bruken av feltene.
17.04.2012
BSK Bank IG ver 1 av Pain.002.001.03 CustomerPaymentStatusReport 201201
Side 3 av 19
1. Introduksjon
1.1 Funksjonell beskrivelse
The CustomerPaymentStatusReport message, (CPSR) utveksles mellom en finansiell institusjon som har
mottatt en betalingsinstruksjon (CCT) og den part som har initiert betalingsoppdraget (InitiatingParty).
I Norge vil status rapporten benyttes på 3 nivå:
- Rapport genereres etter at finansinstitusjonen har foretatt en syntax kontroll av
mottatt fil for å se om filen er lesbar, og knyttet til en kundeavtale og hvorvidt de
kan påta seg ansvaret for mottatt fil på teknisk nivå. (tilsvarer CONTRL i EDIFACT
standard)
- Rapport angir status på betalingsoppdrag etter innlesning hos finansinstitusjonen,
og angir hvorvidt hele det mottatte oppdraget kan gjennomføres i henhold til
instruks, eventuelt årsak til at hele oppdraget avvises. Rapporten kan også angi
status på transaksjonsnivå for de enkelte transaksjoner i betalingsoppdraget, både
ved avvisning i henhold til instruksjon, med angivelse av årsak, og eventuelt også
for godkjente transaksjone (tilsvarer BANSTA i EDIFACT standard).
- Rapport angir endring i status med årsakskode for betalingstransaksjoner som
tidligere har blitt mottatt og akseptert for effektuering i henhold til instruks, men
som allikevel ikke kan gjennomføres.
CPSR-meldingen refererer til det opprinnelige betalingsoppdrag, ved hjelp av referansenr, eller en
kombinasjon av referansebegrep og andre elementer i det opprinnelige oppdraget. Meldingen skal
inneholde tilstrekkelig informasjon som Initiating Party trenger for å oppdatere sine reskontro med
statusen for et betalingsoppdrag, eventuelt grunnlag for å foreta nødvendige korrigeringer for at et
betalingsoppdrag skal la seg gjennomføre.
1.1.1 Omfang av meldingssettet
pain.002.001.03 CustomerPaymentStatusReportV03: brukes til å rapportere status på betalingsoppdraget
fram til at betaling gjennomføres . Utveksles mellom en finansiell institusjon som har blitt instruert om å
utføre et betalingsoppdrag, og oppdragsgiver (InitiatingParty) . Bruk av denne meldingstypen avtales
mellom oppdragsgiver og bank/formidler.
Denne implementasjonsguide dekker Customer Payment Status Report V03.
CPSR-meldinger brukes både for å dekke innenlandske- og grensekryssende betalinger.
Meldingen inngår i et sett med meldinger som er nødvendige for å kunne tilby elektronisk initierte
betalingsoppdrag.. De øvrige meldingstypene er:
pain.001.001.03 CustomerCreditTransferInitiationV03: brukes til å initiere et betalingsoppdrag. Den
sendes fra betaler til betalers bank, eventuelt via en formidler.
pain.002.001.03 CustomerPaymentStatusReportV03: brukes til å rapportere status på betalingsoppdraget
fram til at betaling gjennomføres . Den blir sendt fra betalers bank eller via formidler tilbake til betaler. Bruk
av denne meldingstypen avtales mellom betaler og bank/formidler.
17.04.2012
BSK Bank IG ver 1 av Pain.002.001.03 CustomerPaymentStatusReport 201201
Side 4 av 19
1. Introduksjon
pain.008.001.02 CustomerDirectDebitInitiationV02 *: brukes for kreditorinitiert betalingsoppdrag
* Merk! Denne meldingstypen brukes for tiden ikke i Norge
camt055.001.01 CustomerPaymentCancelationRequestV01 *: brukes til å sende en stoppordre på et
tidligere innsendt betalingsoppdrag. Den sendes fra betaler til betalers bank, eventuelt via en formidler.
* Merk! Denne meldingstypen brukes for tiden ikke i Norge
Denne implementasjonsguide dekker Customer Payment Status Report V03.
CPSR-meldinger brukes både for å dekke innenlandske- og grensekryssende betalinger.
17.04.2012
BSK Bank IG ver 1 av Pain.002.001.03 CustomerPaymentStatusReport 201201
Side 5 av 19
2. Eksempel
2. Eksempler på bruk av CustomerPaymentStatusReport
2.1 Kvittering på mottatt betalingsoppdrag hvor oppdraget kan gjennomføres
I dette eksemplet har kontoeier (Debtor) initiert betalingsoppdrag (CCTI). Betalers konto er i Bank A
(DebtorAgent). Betalingsmottaker (Creditor) har sin konto i Bank B (CreditorAgent). (Eksempelvis lønn,
Betaler genererer i sitt system en CCTI-melding som sendes til betalers bank (Bank B) med instruksjon om
overføring av beløp til kreditors konto i Bank B.
Betalers bank validerer mottatt betalingsoppdrag. Dette skjer ofte i to steg:
først en syntakskontroll som genererer en tilbakemelding på om innsendt fil kan behandles,
dernest en validering av innholdet i betalingsoppdraget, og om finansinstitusjonen kan påta seg ansvaret for
å gjennomføre oppdraget.
I begge steg kan det sendes en kvittering (CPSR) tilbake til utsteder av betalingsordren. I dette tilfellet er alle
betalinger i oppdraget ok, og det holder at CPSR inneholder nivå a og b.
Betalinger kan utføres på angitt forfallsdato, og transaksjon med informasjon fra CCT-melding sendes bank B
for godskrift av kreditors konto og utsending av informasjon om kreditering til betalingsmottaker.
17.04.2012
BSK Bank IG ver 1 av Pain.002.001.03 CustomerPaymentStatusReport 201201
Side 6 av 19
2. Eksempel
2.2 Kvittering på mottatt betalingsoppdrag hvor enkelte av transaksjonene avvises
Steg:
I dette eksemplet har kontoeier (Debtor) initiert betalingsoppdrag (CCTI). Hvor enkelte av betalingene
inneholder feil som gjør at de ikke kan effektueres
Betalers bank validerer mottatt betalingsoppdrag, og sender en kvittering (CPSR) tilbake til utsteder av
betalingsordren. Siden det i dette tilfellet avdekkes at enkelte betalinger ikke kan gjennomføres, må
referanser til hver enkelt betaling i det innsendte oppdraget være med i statusrapporten, med angivelse av
Betaler mottar statusrapporten og leser denne inn i sitt ERP system. Hvor status oppdateres i reskontro.
Betalinger som har blitt avvist, må korrigeres på grunnlag av avvisningsårsak, og sendes inn på nytt.
17.04.2012
BSK Bank IG ver 1 av Pain.002.001.03 CustomerPaymentStatusReport 201201
Side 7 av 19
2. Eksempel
2.3 Statusrapport på innsendt transaksjon som avvises i gjennomføringsøyeblikket
I dette eksemplet har vi tatt utgangspunkt i innsendt betalingsoppdrag ble validert og godkjent (eksempel 1).
Ved betalingstidspunktet mangler det derimot dekning på konto for å få gjennomført enkelte betalinger.
Betalers bank genererer en CPSR med de avviste betalingene, og angivelse av årsak til at de ikke ble
gjennomført.
17.04.2012
BSK Bank IG ver 1 av Pain.002.001.03 CustomerPaymentStatusReport 201201
Side 8 av 19
3. Teknisk beskrivelse
3. Melding Pain.002.001.03 – CustomerPaymentStatusReport V03 Teknisk beskrivelse
3.1 Bruk av melding
CPSR-meldingen kan benyttes for å gi status både for innlandsbetalinger og for grensekryssende betalinger.
CPSR-meldingen identifiseres i xml-skjemaet på følgende måte:
urn: iso: std: iso: 20022: tech: xsd: pain.002.001.03
En CPSR-melding sendes av finansiell institusjon som har mottatt en instruksjon om å gjennomføre et
betalingsoppdrag, og benyttes for å gi oppdragsgiver om status for istruksjonen. Enten påp filnivå eller
transaksjonsnivå.
Bruken av en CPSR-melding vil alltid være styrt av avtale mellom kunden og den finansielle institusjon.
Meldingen kan benyttes for å gi informasjon om status på mottatt oppdrag fra kunden. Dette kan være for å
angi hvorvidt innsendt fil er av en teknisk kvalitet som gjør det mulig for finansinstitusjonen å behandle
innholdet i filen, og at dedt finnes en avtale filen kan knyttes opp mot..
Dernest kan meldingen benyttes for å gi status på betalingsoppdragene (Credit transfr eller direct debit) i
filen, hvorvidt de kan gjennomføres eller ei. På dette nivået refereres det til de opprinnelige instruksjonene
ved bruk av referansebegreper.
3.2 Meldingsoppbygging
CPSR-melding basert på ISO20022 PAIN.002.001.03 er bygd opp av tre nivåer, vist i figur under, og alle må
være med i en melding.
17.04.2012
BSK Bank IG ver 1 av Pain.002.001.03 CustomerPaymentStatusReport 201201
Side 9 av 19
4. Struktur
4
4.1
Struktur
Forklaring til tabellene
GENERELLE PRINSIPPER FOR TABELLEN SOM ER BENYTTET FOR Å BESKRIVE FORMAT OG STRUKTUR FOR
CCT-MELDING
Alle elementer som må være med (Mandatory) i ISO20022. PAIN 002.001.03, er med i den norske MIG,
det samme gjelder for elementer som kan være med eller er avhengige av gitte kriterier.
Elementer som ikke benyttes i norsk betalingsformidling er ikke tatt med i denne MIG. Dette gjelder selv
om de er tatt med i “ISO 20022 Message Definition Report” eller i “CGI Implementation Guide for ISO
20022 CustomerPaymentStatusReport”. Dette er gjort for å forenkle bruken MIG’en
4.1.2 Formatspesifikasjon
Under er en forklaring til kolonnene i tabellene
Krav til karaktersett er ISO UTF8. Ønskes det brukt annet karaktersett fra kunde til bank, må dette avtales
med bank i det enkelte tilfelle.
ISO Index No. Referansenummer som henviser til relatert feltbeskrivelse i ISO 20022 Message Definition
Report”
Message Item refererer til det faktiske tagnavn i XML. Som angis i kolonnen XML Tag Name. Det kan være
et Meldingselement (som kan sammenlignes med “felt” i en tradisjonell melding), eller en Meldings
Komponent (det vil si en bunt med informasjon bestående av flere forskjellige meldingselement). Hvert
meldingselement komplementeres med hva slags type element det er (angis i kolonnen Type).
Tag Name, Den spesifikke koden knyttet til et XML-element, og som vil inngå i XML Schema for å
identifisere et XML-element. “Tag Name” vil starte strengen med informasjon som skal inngå i elementet
(f.eks. <Dbtr>) og strengen avsluttes med den samme tagen med en forutgående slash (f.eks. </Dbtr>).
Structural Sequence: Angir hvor i meldingsstrukturen elementet er plassert
BSK Bank IG ver 1 av Pain.002.001.03 CustomerPaymentStatusReport 201201
Side 10 av 19
4. Struktur
Multiplicity, angir hvor mange ganger et elementet kan/skal være med
Type, angir den type verdi som skal overføres for det aktuelle elementet i XML-notasjon. Det er 7
forskjellige Data Type representasjoner som kan benyttesi en CCT-melding: Identifier, Code, Text, Rate,
Date Time, Amount, Indicator.
Attributter er angitt med prefiks @.
Use in IG, Her angir BSK klassifisering som er fastsatt i BSK CCT-melding MIG. ISO 20022 benytter
klassifiseringene 1..n for mandatory, og 0..n for optional. BSK MIG har en mer gradert klassifisering.
Følgende klassifiseringer benyttes i denne kolonnen:
Definitions / Special comments, angir definisjon av det aktuelle elementet, regler for utfylling, lovlige
verdier mm, i henhold til ISO 20022 I kursiv vil det stå forklaringer på bruken av elementet i det norske
markedet
BSK Bank IG ver 1 av Pain.002.001.03 CustomerPaymentStatusReport 201201
Side 11 av 19
5. Meldings funksjonalitet
5. Message Functionality
The message starts with the element “Document” that identifies what iso standard is used, and what
message type it is. In this case it is:
“urn:iso:std:iso:20022:tech:xsd:pain.002.001.03”
This message is built up by three building blocks: GroupHeader, OriginalGroupInformationAndStatus and
OriginalPaymentInformationAndStatus.
5.0.1 Group Header Functionality
This building block is mandatory and present once. It contains elements such as MessageIdentification,
CreationDateAndTime.
BSK Bank IG ver 1 av Pain.002.001.03 CustomerPaymentStatusReport 201201
Side 12 av 19
5. Meldings funksjonalitet
5.0.2 Original Group Information And Status Functionality
This building block is mandatory and present once. It contains elements such as
OriginalMessageIdentification,
OriginalMessageNameIdentification, GroupStatus.
5.0.3 Original Payment Information And Status Functionality
This building block is optional and repetitive. It contains elements referencing the original instruction (for
example
OriginalEndToEndIdentification), elements relating to the CustomerPaymentStatusReport (for example
StatusReasonInformation). The OriginalPaymentInformationAndStatus block may also transport a set of
elements from
the original instruction.
BSK Bank IG ver 1 av Pain.002.001.03 CustomerPaymentStatusReport 201201
Side 13 av 19
5.1 Funksjonell struktur
5.1
Functional Structure
Customer Payment Status Report pain.002.001.03
Bankenes Standardiseringskontor
Implementasjonsguide av Januar 2012
V3 Implementation Guide
ISO
Index
No.
0.0
Or
Message Item
Tag Name
Mult.
Type
Use
in IG
Defenitions / Spesial comments
<CstmrPmtStsRpt>
Structural
Sequence
-
[1..1]
M
Message root, identifying message type
1.0
GroupHeader
<GrpHdr>
+
[1..1]
M
Set of characteristics shared by all individual transactions included in
the status report message.
1.1
MessageIdentification
<MsgId>
++
[1..1]
M
Point to point reference, as assigned by the instructing party, and sent
to the next party in the chain to unambiguously identify the message.
Text
In status reports (PSR) initiated by an incomming message, this
original reference will be used.
Unique for each customer min. 3 month
1.2
CreationDateTime
<CreDtTm>
++
[1..1]
1.3
InitiatingParty
<InitgPty>
++
[0..1]
DateTime
M
Date and time at which the statusreport message was created.
R
Party that initiates the status message
Used to identify bank (BIC) and Customer who has initiated the
original message.
9.1.0
Name
<Nm>
+++
[0..1]
Identification
OrganisationIdentification
<Id>
<OrgId>
+++
++++
[0..1]
[1..1]
9.1.14
BICOrBEI
<BICOrBEI>
+++++
[0..1]
Identifier
C
Only used to identify the sender of Status Message - BANK (Bank BIC).
9.1.15
9.1.16
Other
Identification
<Othr>
<Id>
+++++
++++++
[0..n]
[1..1]
Text
C
M
Only used to identify the receiver of the Status Message - CUST
9.1.17
9.1.18
SchemeName
Code
<SchmeNm>
<Cd>
++++++
+++++++
[0..1]
[1..1]
Code
R
M
2.0
OriginalGroupInformationAndStatus
<OrgnlGrpInfAndSts>
+
[1..1]
2.1
OriginalMessageIdentification
<OrgnlMsgId>
++
[1..1]
2.2
OriginalMessageNameIdentification
<OrgnlMsgNmId>
++
[1..1]
9.1.12
9.1.13
{Or
Max140Text
maxLength:140
minLength: 1
R
R
M
The Sender of the Message identification is sent either in <BICorBEI>
or <Othr> with <SchmeNm><Cd> = BANK; not both.
In Norway BIC is always used
{{Or
2.4
OriginalNumberOfTransactions
2.5
OriginalControlSum
2.6
GroupStatus
<OrgnlNbOfTxs>
<OrgnlCtrlSum>
<GrpSts>
++
++
++
[0..1]
[0..1]
[0..1]
BANK: Sender of Status Message other than BIC
CUST: Receiver of Status Message
M
Original group information concerning the group of
transactions, to which the status report message refers to
Max35Text
maxLength: 35
minLength: 1
M
M Point to point reference, as assigned by the original instructing party,
to unambiguously identify the original message.
Max35Text
Format:
maxLength: 35
minLength: 1
M
Max15Numeric
Text
Format:
[0-9]{1,15}
BD
DecimalNumber
Format:
fractionDigits: 17
totalDigits: 18
BD
TransactionGroup
Status Code
C
Refers to MessageIdentification in Group Header e.g.. in Pain
001.001.03
Specifies the original message name identifier to which the message
refers.
Refers to Name in Group Header , e.g.. in Pain 001.001.03
If supplied by originator in the initiation message, will be echoed back.
Refers to NumberOfTransactions in Group Header e.g.. in Pain
001.001.03
If supplied by originator in the initiation message, will be echoed back.
Refers to ControlSum in Group Header e.g.. in Pain 001.001.03
Specifies the status of a group of transactions.
ACCP - AcceptedCustomerProfile Preciding check of technical
validation was successful. Customer profile check was
also successful.
The financial institution has taken the responsibility to
forward the transaction(s) for settlement on instructed
date .
ACTC - AcceptedTechnicalValidation. Authentication and
syntactical and semantical validation are successful.
Syntax control accepted
PART - Partially accepted and rejected (detailed information
on transaction level)
RJCT - Rejected Payment initiation or individual transaction
included in the payment initiation has been rejected.
2.7
StatusReasonInformation
2.9
<StsRsnInf>
++
[0..n]
StatusReason
Information
element
BD
If GroupStatus is present and is different from RJCT then
StatusReasonInformation / AdditionalInformation
must be absent.
Dependent upon bank's reporting capabilities, and based on Group
Status codes.
Set of elements used to provide detailed information on the status
reason StatusReasonRule
Reason
<Rsn>
+++
[0..1]
StatusReason
Choice element
BD
Specifies the reason for the status report
Code
<Cd>
++++
[1..1]
External
Organisation
Identification
Code
: maxLength: 4
minLength: 1
M
Code required from External Code List. If a bank's status code is
supported other than a code from the External Code List, then the bank
status code is shown under <AddtlInf>.
2.12
AdditionalInformation
<AddtlInf>
+++
[0..n]
Max105Text
maxLength: 105
minLength: 1
BD
Further details on the status reason.
Usage: Additional information can be used for several purposes such as
the reporting of repaired information.
Codes used in Bansta may be used here
3.0
OriginalPaymentInformationAndStatus
<OrgnlPmtInfAndSts>
+
[0..n]
Original
PaymentInform
ation element
2.10
{Or
C
Information concerning the original payment information, to
which the status report message refers.
BSK Bank IG ver 1 av Pain.002.001.03 CustomerPaymentStatusReport 201201
Side 14 av 19
5.1 Funksjonell struktur
ISO
Index
No.
3.1
Or
3.4
Message Item
Tag Name
OriginalPaymentInformationIdentification
<OrgnlPmtInfId>
Structural
Sequence
++
PaymentInformationStatus
<PmtInfSts>
++
Mult.
Type
Use
in IG
Defenitions / Spesial comments
[1..1]
Max35Text
maxLength: 35
minLength:
M
Unique identification, as assigned by the original sending party, to
unambiguously identify the original payment information group.
Refers to PaymentInformationIdentification in PaymentInformation in
Pain 001.001.03
[0..1]
TransactionGroup
Status Code
C
Required if reporting on a payment level or combined payment and
transaction levels. Not Used if reporting at a transaction level only.
ACCP - AcceptedCustomerProfile Preciding check of technical
validation was successful. Customer profile check was
also successful.
PART - Partially accepted and rejected (detailed information
on transaction level)
RJCT - Rejected Payment initiation or individual transaction
included in the payment initiation has been rejected.
3.5
StatusReasonInformation
<StsRsnInf>
++
[0..n]
StatusReason
Information
element
C
3.7
Reason
<Rsn>
+++
[0..1]
StatusReason
Choice element
C
Code
<Cd>
++++
[1..1]
Externa
lOrganisation
Identification
Code
: maxLength: 4
minLength: 1
M
3.8
{Or
Set of elements used to provide detailed information on the status
reason.
Code required from External Code List. If a bank's status reason code
is supported other than a code from the External Code List, then the
bank status code is shown under <AddtlInf>.
This message item is part of choice 3.7 Reason
3.10
AdditionalInformation
<AddtlInf>
+++
[0..n]
Max105Text
maxLength: 105
minLength: 1
BD
Further details on the status reason.
Usage: Additional information can be used for several purposes reason
for rejection
3.11
NumberOfTransactionsPerStatus
<NbOfTxsPerSts>
++
[0..n]
NumberOf
TransactionsPerSt
atus3 element(s)
BD
Detailed information on the number of transactions for each identical
transaction status.
3.12
DetailedNumberOfTransactions
<DtldNbOfTxs>
+++
[1..1]
Max15
NumericText
M
Definition: Number of individual transactions contained in the message,
detailed per status.
3.13
DetailedStatus
<DtldSts>
+++
[1..1]
TransactionIndivi
dualStatus3Code
M
Common transaction status for all individual transactions reported.
ACCP - AcceptedCustomerProfile Preciding check of technical
validation was successful. Customer profile check was
also successful.
RJCT - Rejected Payment initiation or individual transaction
included in the payment initiation has been rejected.
3.14
DetailedControlSum
<DtldCtrlSum>
+++
[0..1]
DecimalNumber
fractionDigits: 17
totalDigits: 18
BD
Total of all individual amounts included in the message, irrespective of
currencies, detailed per status.
3.15
TransactionInformationAndStatus
<TxInfAndSts>
++
[0..n]
Payment
TransactionInfor
mation25
element(s)
C
Required if reporting on at the transaction level, at the
payment/transaction level, or the group/payment/transaction
levels. Not Used if reporting at only a group or payment level.
3.16
StatusIdentification
<StsId>
+++
[0..1]
Max35Text
maxLength: 35
minLength: 1
BD
Unique identification, as assigned by an instructing party for an
instructed party, to unambiguously identify
the reported status.
Usage: The instructing party is the party sending the status message
and not the party that sent the original
instruction that is being reported on.
3.17
OriginalInstructionIdentification
<OrgnlInstrId>
+++
[0..1]
Max35Text
maxLength: 35
minLength: 1
BD
Unique identification, as assigned by the original instructing party for
the original instructed party, to
unambiguously identify the original instruction.
3.18
OriginalEndToEndIdentification
<OrgnlEndToEndId>
+++
[0..1]
Max35Text
maxLength: 35
minLength: 1
R
Unique identification, as assigned by the original initiating party, to
unambiguously identify the original
transaction.
3.19
TransactionStatus
<TxSts>
+++
[0..1]
TransactionIndivi
dualStatus3Code
C
Required if reporting on a transaction level. Not Used if reporting at a
transaction level only.
ACCP - AcceptedCustomerProfile Preciding check of technical
validation was successful. Customer profile check was
also successful.
Use of this code is bank dependent based on mutual
agreement
PDNG: Pending further processing (lack of funding)
RJCT - Rejected Payment initiation or individual transaction
included in the payment initiation has been rejected.
3.20
StatusReasonInformation
<StsRsnInf>
+++
[0..n]
StatusReason
Information8
element(s)
BD
3.22
Reason
<Rsn>
++++
[0..1]
StatusReason6
Choice element(s)
BD
Specifies the reason for the status report.
Code
<Cd>
+++++
[1..1]
ExternalStatusRe
ason1Code
maxLength: 4
minLength: 1
M
Most used codes are:
(Telepay relaterte feilkoder)
Max105Text
maxLength: 105
minLength: 1
BD
3.23
3.25
{Or
AdditionalInformation
<AddtlInf>
++++
[0..n]
For aditional codes contact your bank
Code required from External Code List. If a bank's status reason code
is supported other than a code from the External Code List, then the
bank status code is shown under <AddtlInf>.
If banks support ACWC, and Requested Execution Date is changed,
date may be reflected in this tag.
BSK Bank IG ver 1 av Pain.002.001.03 CustomerPaymentStatusReport 201201
Side 15 av 19
5.1.1 GrouHeader
5.1.1 Group Header
Information Structure
ISO
Or
Index
No.
0.0
Message Item
Tag Name
<CstmrPmtStsRpt>
-
[1..1]
M
Message root, identifying message type
1.0
GroupHeader
<GrpHdr>
+
[1..1]
M
1.1
MessageIdentification
<MsgId>
++
[1..1]
Set of characteristics shared by all individual transactions included in
the status report message.
Point to point reference, as assigned by the instructing party, and sent
to the next party in the chain to unambiguously identify the message.
Structural
Sequence
Mult.
Type
Text
Use
in IG
M
Defenitions / Spesial comments
In status reports (PSR) initiated by an incomming message, this original
reference will be used.
Unique for each customer min. 3 month
1.2
CreationDateTime
<CreDtTm>
++
[1..1]
1.3
InitiatingParty
<InitgPty>
++
[0..1]
DateTime
M
Date and time at which the statusreport message was created.
R
Party that initiates the status message
Used to identify bank (BIC) and Customer who has initiated the
original message.
9.1.0
9.1.12
9.1.13
{Or
Name
<Nm>
+++
[0..1]
Identification
<Id>
+++
[0..1]
++++
[1..1]
OrganisationIdentification<OrgId>
Max140Te
xt
maxLengt
h:140
minLength
:1
R
R
M
The Sender of the Message identification is sent either in <BICorBEI>
or <Othr> with <SchmeNm><Cd> = BANK; not both.
In Norway BIC is always used
9.1.14
BICOrBEI
<BICOrBEI>
+++++
[0..1]
9.1.15
Other
<Othr>
+++++
[0..n]
9.1.16
Identification
<Id>
++++++
[1..1]
9.1.17
SchemeName
<SchmeNm>
++++++
[0..1]
<Cd>
+++++++
[1..1]
9.1.18
{{Or Code
17.04.2012
Identifier
C
Only used to identify the sender of Status Message - BANK (Bank BIC).
C
Text
M
Only used to identify the receiver of the Status Message - CUST
R
Code
M
BANK: Sender of Status Message other than BIC
CUST: Receiver of Status Message
BSK Bank IG ver 1 av Pain.002.001.03 CustomerPaymentStatusReport 201201
Side 16 av 19
5.1.2 OriginalGroupInformation
5.1.2 Original Group Information and Status
Information Structure
ISO
Or
Index
No.
2.0
2.1
2.2
Message Item
Tag Name
Use
in IG
Defenitions / Spesial comments
M
Original group information concerning the group of
transactions, to which the status report message refers to
OriginalMessageIdentification
<OrgnlMsgId>
[1..1] Max35Text
maxLength:
35
minLength: 1
M
M Point to point reference, as assigned by the original instructing
party, to unambiguously identify the original message.
[1..1] Max35Text
Format:
maxLength:
35
minLength: 1
[0..1] Max15Numeri
c Text
Format:
[0-9]{1,15}
[0..1] DecimalNumb
er
Format:
fractionDigits:
17
totalDigits: 18
M
OriginalControlSum
2.6
Type
[1..1]
OriginalNumberOfTransactions
<OrgnlNbOfTxs>
2.5
Mult.
OriginalGroupInformationAndStatus
<OrgnlGrpInfAnd +
Sts>
OriginalMessageNameIdentification
<OrgnlMsgNmId>
2.4
Structural
Sequence
GroupStatus
<OrgnlCtrlSum>
<GrpSts>
++
++
++
++
++
[0..1] TransactionGr
oupStatus
Code
Refers to MessageIdentification in Group Header e.g.. in Pain
001.001.03
Specifies the original message name identifier to which the
message refers.
Refers to Name in Group Header , e.g.. in Pain 001.001.03
BD
BD
If supplied by originator in the initiation message, will be echoed
back.
Refers to NumberOfTransactions in Group Header e.g.. in Pain
001.001.03
If supplied by originator in the initiation message, will be echoed
back.
Refers to ControlSum in Group Header e.g.. in Pain 001.001.03
C
Specifies the status of a group of transactions.
ACCP - AcceptedCustomerProfile Preciding check of technical
validation was successful. Customer profile check was also
successful.
The financial institution has taken the responsibility to
forward the transaction(s) for settlement on instructed
date .
ACTC - AcceptedTechnicalValidation. Authentication and
syntactical and semantical validation are successful.
Syntax control accepted
RJCT - Rejected Payment initiation or individual transaction
included in the payment initiation has been rejected.
2.7
StatusReasonInformation
<StsRsnInf>
2.9
2.10
Reason
{Or
2.12
17.04.2012
<Rsn>
++
+++
Code
<Cd>
++++
AdditionalInformation
<AddtlInf>
+++
[0..n]
[0..1]
BD
StatusReason
Information
element
StatusReason
Choice
element
[1..1]
External
Organisation
Identification
Code
: maxLength:
4
minLength: 1
[0..n] Max105Text
maxLength:
105
minLength: 1
BD
If GroupStatus is present and is different from RJCT then
StatusReasonInformation / AdditionalInformation
must be absent.
Dependent
upon bank's reporting capabilities, and based on Group
Status codes.
Set of elements used to provide detailed information on the
status reason StatusReasonRule
Specifies the reason for the status report
M
Code required from External Code List. If a bank's status code is
supported other than a code from the External Code List, then the
bank status code is shown under <AddtlInf>.
BD
Further details on the status reason.
Usage: Additional information can be used for several purposes
such as the reporting of repaired information.
Codes used in Bansta may be used here
BSK Bank IG ver 1 av Pain.002.001.03 CustomerPaymentStatusReport 201201
Side 17 av 19
5.1.3 OriginalPaymentInform
5.1.3 Original Payment Information and Status
Information Structure
ISO
Or
Index
No.
3.0
Message Item
Tag Name
Structural Mult. Type
Sequence
3.1
OriginalPaymentInformationIdentification
<OrgnlPmtInfId>
++
3.4
PaymentInformationStatus<PmtInfSts>
++
OriginalPaymentInformationAndStatus
<OrgnlPmtInfAn +
dSts>
3.5
StatusReasonInformation <StsRsnInf>
++
3.7
Reason
<Rsn>
+++
Code
<Cd>
++++
3.8
{Or
3.10
AdditionalInformation
<AddtlInf>
3.11
NumberOfTransactionsPerStatus
<NbOfTxsPerSts>
++
3.12
DetailedNumberOfTransactions
<DtldNbOfTxs>
+++
3.13
DetailedStatus
<DtldSts>
3.14
DetailedControlSum
<DtldCtrlSum>
3.15
Original
PaymentInf
ormation
element
[1..1] Max35Text
maxLength:
35
minLength:
[0..1] TransactionGr
oupStatus
Code
[0..n] StatusReason
Information
element
[0..1] StatusReason
Choice
element
[1..1] External
Organisation
Identification
Code:
maxLength: 4
minLength: 1
[0..n] Max105Text
maxLength:
105
minLength: 1
Defenitions / Spesial comments
C
Information concerning the original payment information, to
which the status report message refers.
M
Unique identification, as assigned by the original sending party, to
unambiguously identify the original payment information group.
Refers to PaymentInformationIdentification in PaymentInformation in
Pain 001.001.03
Required if reporting on a payment level or combined payment and
transaction levels. Not Used if reporting at a transaction level only.
C
C
ACCP - AcceptedCustomerProfile Preciding check of technical
validation was successful. Customer profile check was
also successful.
RJCT - Rejected Payment initiation or individual transaction
included in the payment initiation has been rejected.
Set of elements used to provide detailed information on the status
reason.
C
M
Code required from External Code List. If a bank's status reason code
is supported other than a code from the External Code List, then the
bank status code is shown under <AddtlInf>.
This message item is part of choice 3.7 Reason
BD
Further details on the status reason.
Usage: Additional information can be used for several purposes
reason for rejection
NumberOf
TransactionsP
erStatus3
element(s)
[1..1] Max15
NumericText
BD
Detailed information on the number of transactions for each identical
transaction status.
M
Definition: Number of individual transactions contained in the
message, detailed per status.
+++
[1..1] Transaction
Individual
Status3 Code
M
Common transaction status for all individual transactions reported.
ACCP - AcceptedCustomerProfile Preciding check of technical
validation was successful. Customer profile check was
also successful.
RJCT - Rejected Payment initiation or individual transaction
included in the payment initiation has been rejected.
+++
[0..1] Decimal
Number
fractionDigits:
17
totalDigits: 18
BD
Total of all individual amounts included in the message, irrespective
of currencies, detailed per status.
TransactionInformationAndStatus
<TxInfAndSts>
++
[0..n]
C
Required if reporting on at the transaction level, at the
payment/transaction level, or the
group/payment/transaction levels. Not Used if reporting at
only a group or payment level.
3.16
StatusIdentification
+++
[0..1] Max35Text
maxLength:
35
minLength: 1
BD
3.17
OriginalInstructionIdentification
<OrgnlInstrId>
+++
BD
3.18
OriginalEndToEndIdentification
<OrgnlEndToEndId +++
>
3.19
TransactionStatus
[0..1] Max35Text
maxLength:
35
minLength: 1
[0..1] Max35Text
maxLength:
35
minLength: 1
[0..1] TransactionIn
dividualStatus
3Code
Unique identification, as assigned by an instructing party for an
instructed party, to unambiguously identify
the reported status.
Usage: The instructing party is the party sending the status message
and not the party that sent the original
instruction that is being reported on.
Unique identification, as assigned by the original instructing party for
the original instructed party, to
unambiguously identify the original instruction.
<StsId>
<TxSts>
+++
[0..n]
Use
in IG
+++
[0..n]
Payment
TransactionIn
formation25
element(s)
R
Unique identification, as assigned by the original initiating party, to
unambiguously identify the original
transaction.
C
Required if reporting on a transaction level. Not Used if reporting at a
transaction level only.
ACCP - AcceptedCustomerProfile Preciding check of technical
validation was successful. Customer profile check was
also successful.
RJCT - Rejected Payment initiation or individual transaction
included in the payment initiation has been rejected.
BSK Bank IG ver 1 av Pain.002.001.03 CustomerPaymentStatusReport 201201
Side 18 av 19
5.1.3 OriginalPaymentInform
ISO
Or
Index
No.
3.20
Message Item
StatusReasonInformation <StsRsnInf>
+++
3.22
Reason
<Rsn>
++++
Code
<Cd>
+++++
AdditionalInformation
<AddtlInf>
++++
3.23
3.25
{Or
Tag Name
Structural Mult. Type
Sequence
[0..n] StatusReason
Information8
element(s)
[0..1] StatusReason
6 Choice
element(s)
[1..1] External
StatusReason
1Code
maxLength: 4
minLength: 1
[0..n] Max105Text
maxLength:
105
minLength: 1
Use
in IG
Defenitions / Spesial comments
BD
BD
Specifies the reason for the status report.
M
Code required from External Code List. If a bank's status reason code
is supported other than a code from the External Code List, then the
bank status code is shown under <AddtlInf>.
BD
If banks support ACWC, and Requested Execution Date is changed,
date may be reflected in this tag.
BSK Bank IG ver 1 av Pain.002.001.03 CustomerPaymentStatusReport 201201
Side 19 av 19