BSK implementeringsguide ISO PAIN Customer Payment Status Report

Transkript

1 BSK implementeringsguide ISO PAIN ustomer Payment Status Report Bankenes felles implementasjonsguide Basert på ommon Global Implementation GI Guide for ISO ustomerpaymentstatusreport (PSR) of July 2010 januar 2012

2 Endringskatalog Innhold Dato Ver Utført av endringer orten Holter Første versjon. Innhold Side 1. Innledning Funksjonell beskrivelse Omfang av meldingssettet 4 2. Eksempler på bruk av ustomerpaymentstatusreport Kvittering på mottatt betalingsoppdrag hvor oppdraget kan gjennomføres Kvittering på mottatt betalingsoppdrag hvor enkelte av transaksjonene avvises Statusrapport på innsendt transaksjon som avvises i gjennomføringsøyeblikket 8 3. elding Pain ustomerpaymentstatusreport V03 Teknisk beskrivelse Bruk av melding eldingsoppbygging 9 4 Struktur Forklaring til tabellene Formatspesifikasjon essage Functionality Group Header Functionality Original Group Information And Status Functionality Original Payment Information And Status Functionality Functional Structure Group Header Original Group Information And Status Original Payment Information And Status 18 BSK Bank IG ver 1 av Pain ustomerpaymentstatusreport Side 2 av 19

3 1. Introduksjon 1. Innledning Implementasjonsguiden er utarbeidet i regi av BSK. Denne implementasjonsguiden for ustomer Payment Status Report er basert på ISO essage Definition Report (DR) og ommon Global Implementation GI Guide for ISO ustomer Payment Status Report (PSR) of July 2010 Implementasjonsguiden beskriver hvordan XL ISO 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 essage Definition Report (DR) og essage Usage Guideline (UG) kan lastes ned fra: ommon Global Implementation initiative (ISO GI Initiative) is a SWIFT comunity dedicated to the ommon Global ImplementationInitiative (GI). ain objective of the Group is to define one common globalimplementation standard for ISO messages in the orporate-to-bank space. ålgruppe ustomer 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 PSR-meldinger, med fokus på funksjonalitet og omfang. Rapporten skal nyttes av finansinstitusjoner til å kvittere tilbake til oppdragsgiver som har benyttet ustomerredittransfer 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 BSK Bank IG ver 1 av Pain ustomerpaymentstatusreport Side 3 av 19

4 1. Introduksjon 1.1 Funksjonell beskrivelse The ustomerpaymentstatusreport message, (PSR) utveksles mellom en finansiell institusjon som har mottatt en betalingsinstruksjon (T) 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 ONTRL i EDIFAT 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 EDIFAT 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. PSR-meldingen refererer til det opprinnelige betalingsoppdrag, ved hjelp av referansenr, eller en kombinasjon av referansebegrep og andre elementer i det opprinnelige oppdraget. eldingen 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 Omfang av meldingssettet pain ustomerpaymentstatusreportv03: 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 ustomer Payment Status Report V03. PSR-meldinger brukes både for å dekke innenlandske- og grensekryssende betalinger. eldingen inngår i et sett med meldinger som er nødvendige for å kunne tilby elektronisk initierte betalingsoppdrag.. De øvrige meldingstypene er: pain ustomerredittransferinitiationv03: brukes til å initiere et betalingsoppdrag. Den sendes fra betaler til betalers bank, eventuelt via en formidler. pain ustomerpaymentstatusreportv03: 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 BSK Bank IG ver 1 av Pain ustomerpaymentstatusreport Side 4 av 19

5 1. Introduksjon pain ustomerdirectdebitinitiationv02 *: brukes for kreditorinitiert betalingsoppdrag * erk! Denne meldingstypen brukes for tiden ikke i Norge camt ustomerpaymentancelationrequestv01 *: brukes til å sende en stoppordre på et tidligere innsendt betalingsoppdrag. Den sendes fra betaler til betalers bank, eventuelt via en formidler. * erk! Denne meldingstypen brukes for tiden ikke i Norge Denne implementasjonsguide dekker ustomer Payment Status Report V03. PSR-meldinger brukes både for å dekke innenlandske- og grensekryssende betalinger BSK Bank IG ver 1 av Pain ustomerpaymentstatusreport Side 5 av 19

6 2. Eksempel 2. Eksempler på bruk av ustomerpaymentstatusreport 2.1 Kvittering på mottatt betalingsoppdrag hvor oppdraget kan gjennomføres I dette eksemplet har kontoeier (Debtor) initiert betalingsoppdrag (TI). Betalers konto er i Bank A (DebtorAgent). Betalingsmottaker (reditor) har sin konto i Bank B (reditoragent). (Eksempelvis lønn, Betaler genererer i sitt system en TI-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 (PSR) tilbake til utsteder av betalingsordren. I dette tilfellet er alle betalinger i oppdraget ok, og det holder at PSR inneholder nivå a og b. Betalinger kan utføres på angitt forfallsdato, og transaksjon med informasjon fra T-melding sendes bank B for godskrift av kreditors konto og utsending av informasjon om kreditering til betalingsmottaker BSK Bank IG ver 1 av Pain ustomerpaymentstatusreport Side 6 av 19

7 2. Eksempel 2.2 Kvittering på mottatt betalingsoppdrag hvor enkelte av transaksjonene avvises Steg: I dette eksemplet har kontoeier (Debtor) initiert betalingsoppdrag (TI). Hvor enkelte av betalingene inneholder feil som gjør at de ikke kan effektueres Betalers bank validerer mottatt betalingsoppdrag, og sender en kvittering (PSR) 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 BSK Bank IG ver 1 av Pain ustomerpaymentstatusreport Side 7 av 19

8 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 PSR med de avviste betalingene, og angivelse av årsak til at de ikke ble gjennomført BSK Bank IG ver 1 av Pain ustomerpaymentstatusreport Side 8 av 19

9 3. Teknisk beskrivelse 3. elding Pain ustomerpaymentstatusreport V03 - Teknisk beskrivelse 3.1 Bruk av melding PSR-meldingen kan benyttes for å gi status både for innlandsbetalinger og for grensekryssende betalinger. PSR-meldingen identifiseres i xml-skjemaet på følgende måte: urn: iso: std: iso: 20022: tech: xsd: pain En PSR-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 PSR-melding vil alltid være styrt av avtale mellom kunden og den finansielle institusjon. eldingen 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 (redit 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 eldingsoppbygging PSR-melding basert på ISO20022 PAIN er bygd opp av tre nivåer, vist i figur under, og alle må være med i en melding BSK Bank IG ver 1 av Pain ustomerpaymentstatusreport Side 9 av 19

10 4. Struktur 4 Struktur 4.1 Forklaring til tabellene GENERELLE PRINSIPPER FOR TABELLEN SO ER BENYTTET FOR Å BESKRIVE FORAT OG STRUKTUR FOR T-ELDING Alle elementer som må være med (andatory) i ISO PAIN , er med i den norske IG, 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 IG. Dette gjelder selv om de er tatt med i ISO essage Definition Report eller i GI Implementation Guide for ISO ustomerpaymentstatusreport. Dette er gjort for å forenkle bruken IG en 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 essage Definition Report essage Item refererer til det faktiske tagnavn i XL. Som angis i kolonnen XL Tag Name. Det kan være et eldingselement (som kan sammenlignes med felt i en tradisjonell melding), eller en eldings 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 XL-element, og som vil inngå i XL Schema for å identifisere et XL-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 ustomerpaymentstatusreport Side 10 av 19

11 4. Struktur ultiplicity, 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 XL-notasjon. Det er 7 forskjellige Data Type representasjoner som kan benyttesi en T-melding: Identifier, ode, Text, Rate, Date Time, Amount, Indicator. Attributter er angitt med Use in IG, Her angir BSK klassifisering som er fastsatt i BSK T-melding IG. ISO benytter klassifiseringene 1..n for mandatory, og 0..n for optional. BSK IG 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 I kursiv vil det stå forklaringer på bruken av elementet i det norske markedet BSK Bank IG ver 1 av Pain ustomerpaymentstatusreport Side 11 av 19

12 5. eldings funksjonalitet 5. essage 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 This message is built up by three building blocks: GroupHeader, OriginalGroupInformationAndStatus and OriginalPaymentInformationAndStatus Group Header Functionality This building block is mandatory and present once. It contains elements such as essageidentification, reationdateandtime. BSK Bank IG ver 1 av Pain ustomerpaymentstatusreport Side 12 av 19

13 5. eldings funksjonalitet Original Group Information And Status Functionality This building block is mandatory and present once. It contains elements such as OriginalessageIdentification, OriginalessageNameIdentification, GroupStatus 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 ustomerpaymentstatusreport (for example StatusReasonInformation). The OriginalPaymentInformationAndStatus block may also transport a set of elements from the original instruction. BSK Bank IG ver 1 av Pain ustomerpaymentstatusreport Side 13 av 19

14 5.1 Funksjonell struktur 5.1 Functional Structure ustomer Payment Status Report pain Bankenes Standardiseringskontor Implementasjonsguide av Januar 2012 ISO Index No. Or essage Item Tag Name Structural Sequence ult. Type Use in IG V3 Implementation Guide Defenitions / Spesial comments 0.0 <stmrpmtstsrpt> - [1..1] essage root, identifying message type 1.0 GroupHeader <GrpHdr> + [1..1] Set of characteristics shared by all individual transactions included in the status report message. 1.1 essageidentification <sgid> ++ [1..1] Text Point to point reference, as assigned by the instructing party, and sent to the next party in the chain to unambiguously identify the message. In status reports (PSR) initiated by an incomming message, this original reference will be used. Unique for each customer min. 3 month 1.2 reationdatetime <redttm> ++ [1..1] DateTime Date and time at which the statusreport message was created. 1.3 InitiatingParty <InitgPty> ++ [0..1] R Party that initiates the status message Used to identify bank (BI) and ustomer who has initiated the original message Name <Nm> +++ [0..1] ax140text maxlength:140 R Identification <Id> +++ [0..1] R {Or OrganisationIdentification <OrgId> ++++ [1..1] The Sender of the essage identification is sent either in <BIorBEI> or <Othr> with <SchmeNm><d> = BANK; not both. In Norway BI is always used BIOrBEI <BIOrBEI> [0..1] Identifier Only used to identify the sender of Status essage - BANK (Bank BI) Other <Othr> [0..n] Identification <Id> [1..1] Text Only used to identify the receiver of the Status essage - UST SchemeName <SchmeNm> [0..1] R {{Or ode <d> [1..1] ode BANK: Sender of Status essage other than BI UST: Receiver of Status essage 2.0 OriginalGroupInformationAndStatus <OrgnlGrpInfAndSts> + [1..1] Original group information concerning the group of transactions, to which the status report message refers to 2.1 OriginalessageIdentification <OrgnlsgId> ++ [1..1] ax35text maxlength: OriginalessageNameIdentification <OrgnlsgNmId> ++ [1..1] ax35text Format: maxlength: 35 Point to point reference, as assigned by the original instructing party, to unambiguously identify the original message. Refers to essageidentification in Group Header e.g.. in Pain Specifies the original message name identifier to which the message refers. Refers to Name in Group Header, e.g.. in Pain OriginalNumberOfTransactions <OrgnlNbOfTxs> ++ [0..1] ax15numeric Text Format: [0-9]{1,15} 2.5 OriginalontrolSum <OrgnltrlSum> ++ [0..1] DecimalNumber Format: fractiondigits: 17 totaldigits: 18 If supplied by originator in the initiation message, will be echoed back. Refers to NumberOfTransactions in Group Header e.g.. in Pain If supplied by originator in the initiation message, will be echoed back. Refers to ontrolsum in Group Header e.g.. in Pain GroupStatus <GrpSts> ++ [0..1] TransactionGroup Status ode Specifies the status of a group of transactions. AP - AcceptedustomerProfile Preciding check of technical validation was successful. ustomer profile check was also successful. The financial institution has taken the responsibility to forward the transaction(s) for settlement on instructed date. AT - AcceptedTechnicalValidation. Authentication and syntactical and semantical validation are successful. Syntax control accepted PART - Partially accepted and rejected (detailed information on transaction level) RJT - Rejected Payment initiation or individual transaction included in the payment initiation has been rejected. 2.7 StatusReasonInformation <StsRsnInf> ++ [0..n] StatusReason Information element If GroupStatus is present and is different from RJT 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 2.9 Reason <Rsn> +++ [0..1] StatusReason hoice element 2.10 {Or ode <d> ++++ [1..1] External Organisation Identification ode : maxlength: 4 Specifies the reason for the status report ode required from External ode List. If a bank's status code is supported other than a code from the External ode List, then the bank status code is shown under <AddtlInf> AdditionalInformation <AddtlInf> +++ [0..n] ax105text maxlength: 105 Further details on the status reason. Usage: Additional information can be used for several purposes such as the reporting of repaired information. odes used in Bansta may be used here 3.0 OriginalPaymentInformationAndStatus <OrgnlPmtInfAndSts> + [0..n] Original PaymentInform ation element Information concerning the original payment information, to which the status report message refers. BSK Bank IG ver 1 av Pain ustomerpaymentstatusreport Side 14 av 19

15 5.1 Funksjonell struktur ISO Index No. Or essage Item Tag Name Structural Sequence ult. Type Use in IG 3.1 OriginalPaymentInformationIdentification <OrgnlPmtInfId> ++ [1..1] ax35text maxlength: 35 minlength: Defenitions / Spesial comments Unique identification, as assigned by the original sending party, to unambiguously identify the original payment information group. Refers to PaymentInformationIdentification in PaymentInformation in Pain PaymentInformationStatus <PmtInfSts> ++ [0..1] TransactionGroup Status ode Required if reporting on a payment level or combined payment and transaction levels. Not Used if reporting at a transaction level only. AP - AcceptedustomerProfile Preciding check of technical validation was successful. ustomer profile check was also successful. PART - Partially accepted and rejected (detailed information on transaction level) 3.5 StatusReasonInformation <StsRsnInf> ++ [0..n] StatusReason Information element 3.7 Reason <Rsn> +++ [0..1] StatusReason hoice element 3.8 {Or ode <d> ++++ [1..1] Externa lorganisation Identification ode : maxlength: 4 RJT - 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. ode required from External ode List. If a bank's status reason code is supported other than a code from the External ode 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] ax105text maxlength: NumberOfTransactionsPerStatus <NbOfTxsPerSts> ++ [0..n] NumberOf TransactionsPerSt atus3 element(s) Further details on the status reason. Usage: Additional information can be used for several purposes reason for rejection Detailed information on the number of transactions for each identical transaction status DetailedNumberOfTransactions <DtldNbOfTxs> +++ [1..1] ax15 NumericText 3.13 DetailedStatus <DtldSts> +++ [1..1] TransactionIndivi dualstatus3ode Definition: Number of individual transactions contained in the message, detailed per status. ommon transaction status for all individual transactions reported. AP - AcceptedustomerProfile Preciding check of technical validation was successful. ustomer profile check was also successful. RJT - Rejected Payment initiation or individual transaction included in the payment initiation has been rejected DetailedontrolSum <DtldtrlSum> +++ [0..1] DecimalNumber fractiondigits: 17 totaldigits: 18 Total of all individual amounts included in the message, irrespective of currencies, detailed per status TransactionInformationAndStatus <TxInfAndSts> ++ [0..n] Payment TransactionInfor mation25 element(s) 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 StatusIdentification <StsId> +++ [0..1] ax35text maxlength: OriginalInstructionIdentification <OrgnlInstrId> +++ [0..1] ax35text maxlength: 35 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 OriginalEndToEndIdentification <OrgnlEndToEndId> +++ [0..1] ax35text maxlength: TransactionStatus <TxSts> +++ [0..1] TransactionIndivi dualstatus3ode R Unique identification, as assigned by the original initiating party, to unambiguously identify the original transaction. Required if reporting on a transaction level. Not Used if reporting at a transaction level only. AP - AcceptedustomerProfile Preciding check of technical validation was successful. ustomer profile check was also successful. Use of this code is bank dependent based on mutual agreement PDNG: Pending further processing (lack of funding) 3.20 StatusReasonInformation <StsRsnInf> +++ [0..n] StatusReason Information8 element(s) 3.22 Reason <Rsn> ++++ [0..1] StatusReason6 hoice element(s) RJT - Rejected Payment initiation or individual transaction included in the payment initiation has been rejected. Specifies the reason for the status report {Or ode <d> [1..1] ExternalStatusRe ason1ode maxlength: AdditionalInformation <AddtlInf> ++++ [0..n] ax105text maxlength: 105 ost used codes are: (Telepay relaterte feilkoder) For aditional codes contact your bank ode required from External ode List. If a bank's status reason code is supported other than a code from the External ode List, then the bank status code is shown under <AddtlInf>. If banks support AW, and Requested Execution Date is changed, date may be reflected in this tag. BSK Bank IG ver 1 av Pain ustomerpaymentstatusreport Side 15 av 19

16 5.1.1 GrouHeader Group Header Information Structure ISO Index No. Or essage Item Tag Name Structural Sequence ult. Type Use in IG Defenitions / Spesial comments 0.0 <stmrpmtstsrpt> - [1..1] essage root, identifying message type 1.0 GroupHeader <GrpHdr> + [1..1] Set of characteristics shared by all individual transactions included in the status report message. 1.1 essageidentification <sgid> ++ [1..1] Text Point to point reference, as assigned by the instructing party, and sent to the next party in the chain to unambiguously identify the message. In status reports (PSR) initiated by an incomming message, this original reference will be used. Unique for each customer min. 3 month 1.2 reationdatetime <redttm> ++ [1..1] DateTime Date and time at which the statusreport message was created. 1.3 InitiatingParty <InitgPty> ++ [0..1] R Party that initiates the status message Used to identify bank (BI) and ustomer who has initiated the original message Name <Nm> +++ [0..1] ax140te R xt maxlengt h:140 minlength : Identification <Id> +++ [0..1] R {Or OrganisationIdentification <OrgId> ++++ [1..1] The Sender of the essage identification is sent either in <BIorBEI> or <Othr> with <SchmeNm><d> = BANK; not both. In Norway BI is always used BIOrBEI <BIOrBEI> [0..1] Identifier Only used to identify the sender of Status essage - BANK (Bank BI) Other <Othr> [0..n] Identification <Id> [1..1] Text Only used to identify the receiver of the Status essage - UST SchemeName <SchmeNm> [0..1] R {{Or ode <d> [1..1] ode BANK: Sender of Status essage other than BI UST: Receiver of Status essage BSK Bank IG ver 1 av Pain ustomerpaymentstatusreport Side 16 av 19

17 5.1.2 OriginalGroupInformation Original Group Information and Status Information Structure ISO Index No. Or essage Item Tag Name 2.0 OriginalGroupInformationAndStatus <OrgnlGrpInfAnd Sts> Structural Sequence ult. Type Use in IG Defenitions / Spesial comments + [1..1] Original group information concerning the group of transactions, to which the status report message refers to 2.1 OriginalessageIdentification <OrgnlsgId> ++ [1..1] ax35text maxlength: OriginalessageNameIdentification <OrgnlsgNmId> ++ [1..1] ax35text Format: maxlength: OriginalNumberOfTransactions <OrgnlNbOfTxs> ++ [0..1] ax15numeri c Text Format: [0-9]{1,15} 2.5 OriginalontrolSum <OrgnltrlSum> ++ [0..1] DecimalNumb er Format: fractiondigits: 17 totaldigits: GroupStatus <GrpSts> ++ [0..1] TransactionGr oupstatus ode 2.7 StatusReasonInformation <StsRsnInf> ++ [0..n] StatusReason Information element 2.9 Reason <Rsn> +++ [0..1] StatusReason hoice element 2.10 {Or ode <d> ++++ [1..1] External Organisation Identification ode : maxlength: AdditionalInformation <AddtlInf> +++ [0..n] ax105text maxlength: 105 Point to point reference, as assigned by the original instructing party, to unambiguously identify the original message. Refers to essageidentification in Group Header e.g.. in Pain Specifies the original message name identifier to which the message refers. Refers to Name in Group Header, e.g.. in Pain If supplied by originator in the initiation message, will be echoed back. Refers to NumberOfTransactions in Group Header e.g.. in Pain If supplied by originator in the initiation message, will be echoed back. Refers to ontrolsum in Group Header e.g.. in Pain Specifies the status of a group of transactions. AP - AcceptedustomerProfile Preciding check of technical validation was successful. ustomer profile check was also successful. The financial institution has taken the responsibility to forward the transaction(s) for settlement on instructed date. AT - AcceptedTechnicalValidation. Authentication and syntactical and semantical validation are successful. Syntax control accepted RJT - Rejected Payment initiation or individual transaction included in the payment initiation has been rejected. If GroupStatus is present and is different from RJT then StatusReasonInformation / AdditionalInformation must Dependent be absent. 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 ode required from External ode List. If a bank's status code is supported other than a code from the External ode List, then the bank status code is shown under <AddtlInf>. Further details on the status reason. Usage: Additional information can be used for several purposes such as the reporting of repaired information. odes used in Bansta may be used here BSK Bank IG ver 1 av Pain ustomerpaymentstatusreport Side 17 av 19

18 5.1.3 OriginalPaymentInform Original Payment Information and Status Information Structure ISO Index No. Or essage Item Tag Name Structural Sequence 3.0 OriginalPaymentInformationAndStatus <OrgnlPmtInfAn dsts> ult. Type Use in IG + [0..n] Original PaymentInf ormation element 3.1 OriginalPaymentInformationIdentification <OrgnlPmtInfId> ++ [1..1] ax35text maxlength: 35 minlength: 3.4 PaymentInformationStatus <PmtInfSts> ++ [0..1] TransactionGr oupstatus ode 3.5 StatusReasonInformation <StsRsnInf> ++ [0..n] StatusReason Information element 3.7 Reason <Rsn> +++ [0..1] StatusReason hoice element 3.8 {Or ode <d> ++++ [1..1] External Organisation Identification ode: maxlength: AdditionalInformation <AddtlInf> +++ [0..n] ax105text maxlength: NumberOfTransactionsPerStatus <NbOfTxsPerSts> ++ [0..n] NumberOf TransactionsP erstatus3 element(s) 3.12 DetailedNumberOfTransactions <DtldNbOfTxs> +++ [1..1] ax15 NumericText 3.13 DetailedStatus <DtldSts> +++ [1..1] Transaction Individual Status3 ode 3.14 DetailedontrolSum <DtldtrlSum> +++ [0..1] Decimal Number fractiondigits: 17 totaldigits: 18 Defenitions / Spesial comments Information concerning the original payment information, to which the status report message refers. Unique identification, as assigned by the original sending party, to unambiguously identify the original payment information group. Refers to PaymentInformationIdentification in PaymentInformation in Pain Required if reporting on a payment level or combined payment and transaction levels. Not Used if reporting at a transaction level only. AP - AcceptedustomerProfile Preciding check of technical validation was successful. ustomer profile check was also successful. RJT - 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. ode required from External ode List. If a bank's status reason code is supported other than a code from the External ode List, then the bank status code is shown under <AddtlInf>. This message item is part of choice 3.7 Reason Further details on the status reason. Usage: Additional information can be used for several purposes reason for rejection Detailed information on the number of transactions for each identical transaction status. Definition: Number of individual transactions contained in the message, detailed per status. ommon transaction status for all individual transactions reported. AP - AcceptedustomerProfile Preciding check of technical validation was successful. ustomer profile check was also successful. RJT - Rejected Payment initiation or individual transaction included in the payment initiation has been rejected. Total of all individual amounts included in the message, irrespective of currencies, detailed per status TransactionInformationAndStatus <TxInfAndSts> ++ [0..n] Payment TransactionIn formation25 element(s) 3.16 StatusIdentification <StsId> +++ [0..1] ax35text maxlength: OriginalInstructionIdentification <OrgnlInstrId> +++ [0..1] ax35text maxlength: OriginalEndToEndIdentification <OrgnlEndToEndId > +++ [0..1] ax35text maxlength: TransactionStatus <TxSts> +++ [0..1] TransactionIn dividualstatus 3ode R 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. 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. Unique identification, as assigned by the original initiating party, to unambiguously identify the original transaction. Required if reporting on a transaction level. Not Used if reporting at a transaction level only. AP - AcceptedustomerProfile Preciding check of technical validation was successful. ustomer profile check was also successful. RJT - Rejected Payment initiation or individual transaction included in the payment initiation has been rejected. BSK Bank IG ver 1 av Pain ustomerpaymentstatusreport Side 18 av 19

19 5.1.3 OriginalPaymentInform ISO Index No. Or essage Item Tag Name Structural Sequence ult. Type Use in IG 3.20 StatusReasonInformation <StsRsnInf> +++ [0..n] StatusReason Information8 element(s) 3.22 Reason <Rsn> ++++ [0..1] StatusReason 6 hoice element(s) 3.23 {Or ode <d> [1..1] External StatusReason 1ode maxlength: AdditionalInformation <AddtlInf> ++++ [0..n] ax105text maxlength: 105 Defenitions / Spesial comments Specifies the reason for the status report. ode required from External ode List. If a bank's status reason code is supported other than a code from the External ode List, then the bank status code is shown under <AddtlInf>. If banks support AW, and Requested Execution Date is changed, date may be reflected in this tag. BSK Bank IG ver 1 av Pain ustomerpaymentstatusreport Side 19 av 19