BSK implementeringsguide ISO PAIN Customer Payment Status Report. Bankenes felles implementasjonsguide

Transkript

1 BSK implementeringsguide ISO PAIN Customer Payment Status Report Bankenes felles implementasjonsguide BSK ver. 1.5 september 2014

2 Endringskatalog Dato Ver Utført av endringer Morten Holter Første versjon Morten Holter Språklig oppdatering og rettelser i tabell. Se Change Control Innhold Innledning Funksjonell beskrivelse Omfang av meldingssettet Eksempler Teknisk beskrivelse Struktur Principles an rules Message Functionality Functional Structure Group header OriginalGroupInformation and Status OriginalPaymentInformation and Status Change Control

3 Innledning Implementasjonsguiden er utarbeidet i regi av BSK. Denne implementasjonsguiden for Customer Payment Status Report er basert på ISO Message Definition Report (MDR) og Common Global Implementation CGI Guide for ISO Customer Payment Status Report of July Implementasjonsguiden beskriver hvordan XML 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 Message Definition Report (MDR) og Message Usage Guideline (MUG) kan lastes ned fra: Common Global Implementation initiative (ISO CGI Initiative) er et "SWIFT community" initiativ hvis hovedoppgave er å definere én felles standard for implementering av ISO meldinger til bruk mellom banker og bankenes bedriftskunder. CGI Implementasjons MIG er tilgjengelig på CGI-MP hjemmeside. Første del av implementasjonsguiden gir en oversikt på generelt grunnlag om bruk av CustomerPaymentStatusReport meldinger, med fokus på funksjonalitet og omfang. Rapporten skal nyttes av finansinstitusjoner til å kvittere tilbake til oppdragsgiver som har benyttet CustomerCreditTransferInitiation meldingen for å 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 Funksjonell beskrivelse CustomerPaymentStatusReport meldingen utveksles mellom en finansiell institusjon som har mottatt en betalingsinstruksjon, en CustomerCreditTransferInitation, 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 å kontrollere 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 instruksjonen 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. CustomerPaymentStatusReport meldingen refererer til det opprinnelige betalingsoppdraget, 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. Omfang av meldingssettet

4 Pain CustomerPaymentStatusReportV03: brukes til å rapportere status på betalingsoppdraget fram til 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 implementasjonsguiden dekker CustomerPaymentStatusReportV03. Meldingen brukes for å ivareta statusrapportering både for innenlandske- og for 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 CustomerCreditTransferInitiationV03: brukes til å initiere et betalingsoppdrag. Den sendes fra betaler til betalers bank, eventuelt via en formidler. pain CustomerDirectDebitInitiationV02 : brukes for kreditorinitiert betalingsoppdrag, så som Avtalegiro og Autogiro. camt CustomerPaymentCancelationRequestV01: brukes til å sende en stoppordre på et tidligere innsendt betalingsoppdrag. Den sendes fra betaler til betalers bank, eventuelt via en formidler. Kontakt din bank for å få vite hvilke meldingstyper de supporterer.

5 Eksempler på bruk av CustomerPaymentStatusReport Kvittering på mottatt betalingsoppdrag hvor oppdraget kan gjennomføres I dette eksemplet har kontoeier (Debtor) initiert et betalingsoppdrag (CustomerCreditTransferInitiation). Betalers konto er i Bank A (DebtorAgent). Betalingsmottaker (Creditor) har sin konto i Bank B (CreditorAgent). (Eksempelvis lønn, pensjon). Betaler genererer i sitt system en CustomerCreditTransferInitiation 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 (CustomerPaymentStatusReport) tilbake til utsteder av betalingsordren. I dette tilfellet er alle betalinger i oppdraget ok, og det holder at CustomerPaymentStatusReport inneholder nivå a og b. Betalinger kan utføres på angitt forfallsdato, og transaksjon med informasjon fra CustomerCreditTransfer melding sendes bank B for godskrift av kreditors konto og utsending av informasjon om kreditering til betalingsmottaker. Kvittering på mottatt betalingsoppdrag hvor enkelte av transaksjonene avvises

6 Steg: I dette eksemplet har kontoeier (Debtor) initiert betalingsoppdrag (CustomerCreditTransferInitiation) hvor enkelte av betalingene inneholder feil som gjør at de ikke kan effektueres. Betalers bank validerer mottatt betalingsoppdrag, og sender en kvittering (CustomerPaymentStatusReport) 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 status. 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. Statusrapport på innsendt transaksjon som avvises i gjennomføringsøyeblikket I dette eksemplet har vi tatt utgangspunkt i at 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 CustomerPaymentStatusReport melding med de avviste betalingene, og angivelse av årsak til at de ikke ble gjennomført. Betaler mottar statusrapporten, og leser den inn i sitt ERP system, og oppdaterer status i reskontro.

7

8 Teknisk beskrivelse Melding Pain CustomerPaymentStatusReport V03 Bruk av melding CustomerPaymentStatusReport-meldingen kan benyttes både for innlandsbetalinger og for grensekryssende betalinger. CustomerPaymentStatusReport-meldingen identifiseres i xml-skjemaet på følgende måte: urn: iso: std: iso: 20022: tech: xsd: pain En CustomerPaymentStatusReport-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 CustomerPaymentStatusReport-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 transfer 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. Meldingsoppbygging CustomerPaymentStatusReport-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.

9 Struktur Forklaring til tabellene GENERELLE PRINSIPPER FOR TABELLEN SOM ER BENYTTET FOR Å BESKRIVE FORMAT OG STRUKTUR FOR ISO Alle elementer som må være med (Mandatory) i ISO20022.meldinger, er med i den norske er med i den norske meldingsguiden. Det samme gjelder dersom de er (Required) i «CGI Implementation Guide» for ISO meldinger, og 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 Message Definition Report eller i CGI Implementation Guide» for ISO meldinger. Dette er gjort for å forenkle bruken av meldingsguiden. Formatspesifikasjon -Standard XML versjon angivelse må spesifisere at XML V. 1.0 blir benyttet, videre må det angis hvilket karaktersett som benyttes. Krav til karaktersett er ISO UTF8. <Document>Koden bør angi riktige navneområdet. Eksempel:<?xml version="1.0" encoding="utf-8"?></document> Under er en forklaring til kolonnene i tabellene: ISO Index No. Or Message Item Tag Name Structural Sequence Mult. Type Use Defenitions / Spesial in comments IG <CstmrCdtTrfInitn> - M Message root, identifying message type ISO Index No. Referansenummer som henviser til relatert feltbeskrivelse i ISO 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 Multiplicity, angir hvor mange ganger et elementet kan/skal være med n n En forekomst (påkrevd) En eller mange forekomster (verdien for n angir max antall) Minimum en er påkrevd. Null eller en forekomst (valgfritt) Null eller mange forekomster (verdien for n angir max antall) 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 benyttes: Identifier, Code, Text, Rate, Date Time, Amount, Indicator. String Alfanumerisk Integer Heltall Decimal Desimaltall Date Dato (YYYY-MM-DD) Time Klokkeslett (HH:MM:SS) DateTime Dato+Klokkeslett (YYYY-MM-DDTHH:MM:SS) Attributter er angitt med Use in IG, Her angir BSK klassifisering som er fastsatt i BSK Customer Credit Transfer-melding MIG. ISO 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: ATTRIBUTES Kode Terminologi Definisjon M Mandatory Påkrevd i ISO og skal brukes i Norge R Required Optional i ISO men skal brukes i Norge C Conditional Avhengig av spesielle forutsetninger Bilaterally Determined Avhengig av utvekslingsavtale mellom Bank og Kunde NU Not Used Benyttes ikke i Norge 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 Da norsk implementasjonsguidelines skal være kompatibel med CGI vil vi ikke ha med elementer som er angitt som NU i CGI sine guidelines. Videre vil BSK IG ikke ha noen mer fleksibel klassifisering enn CGI. Det vil si at elementer som i CGI IG er klassifisert som R, ikke kan klassifiseres som i BSK IG. Derimot kan elementer som av CGI er klassifisert som bli klassifisert som M i BSK.

10 Referanser til ISO dokumentasjon Start merke for Angir meldingstypen meldingen Nivå start merke Inneholder ikke data Blokk start merke Inneholder ikke data. Data element ikke i bruk

11 Principles and Rules for use of Codes Identifying Parties in a message Pain002 We open for the use of DebtorAgent in GRHD as BilateralDependent (used if the bank is one point of entry, and delivers status from another bank) DebtorAgents BIC replaces Other - BANK as Initiating Party Use the same codes as for pain001. IntgPrty: BIC is always used to identify the Financial Institution that is the Initiating party/sender of the pain002 Message Receiver: Other 1 identifies Main Agreement (CUST) Other 2 identifies Sub-Agreement (BANK) If BIC is used by CUST in original pain001 message, BIC must be used as id under the element Other to identify the receiver (CUST)

12 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 This message is built up by three building blocks: GroupHeader, OriginalGroupInformationAndStatus and OriginalPaymentInformationAndStatus.

13 A B C D E F H I J K Functional Structure Customer Payment Status Report pain Bankenes Standardiseringskontor Implementasjonsguide av januar 2012 NO requirements included September 2014 ISO Or Message Item Tag Name Mult. Type Use Defenitions / Spesial comments Index Structural in IG No. Sequence 0.0 <CstmrPmtStsRpt> - [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] Text 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. In status reports (PSR) initiated by an incomming message, this original reference will be used. Unique for each customer 1.2 CreationDateTime <CreDtTm> ++ [1..1] DateTime M 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 (BIC) and Customer who has initiated the original message Identification <Id> +++ [0..1] R {Or OrganisationIdentification <OrgId> ++++ [1..1] 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 BICOrBEI <BICOrBEI> [0..1] Identifier C Only used to identify the sender of Status Message - BANK (Bank BIC) Other <Othr> [0..n] C Identification <Id> [1..1] Text M Only used to identify the receiver of the Status Message - CUST SchemeName <SchmeNm> [0..1] R

14 A B C D E F H I J K ISO Or Message Item Tag Name Mult. Type Use Defenitions / Spesial comments Index Structural in IG No. Sequence {{Or Code <Cd> [1..1] Code M Name of the identification scheme, in a coded form as published in an external list. PAIN and CAMT messages do not cover the banks and their customers need for a unified way of identifying parties, when routing different messages to and from. Norway wants to introduce what we regard as a logical use of codes identifying the parties in a message exchange, across message types, and a uniform use of GroupHeader. Party/Other/Code CUST = Debtor/Creditor relates to Main-Agreement with the financial Institution BANK = Debtor/Creditor relates to a Sub-level Agreement under the main agreement (bilateral agreement customer/bank) i.e special service or related to subsidiary's or divisions. 2.0 OriginalGroupInformationAndStatus <OrgnlGrpInfAndSts> + [1..1] M Original group information concerning the group of transactions, to which the status report message refers to 2.1 OriginalMessageIdentification <OrgnlMsgId> ++ [1..1] Max35Text maxlength: OriginalMessageNameIdentification <OrgnlMsgNmId> ++ [1..1] Max35Text Format: maxlength: OriginalNumberOfTransactions <OrgnlNbOfTxs> ++ [0..1] Max15Numeric Text Format: [0-9]{1,15} 2.5 OriginalControlSum <OrgnlCtrlSum> ++ [0..1] DecimalNumber Format: fractiondigits: 17 totaldigits: 18 M M Point to point reference, as assigned by the original instructing party, to unambiguously identify the original message. Refers to MessageIdentification 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 ControlSum in Group Header e.g.. in Pain

15 6 A B C D E F H I J K ISO Or Message Item Tag Name Mult. Type Use Defenitions / Spesial comments Index Structural in IG No. Sequence 2.6 GroupStatus <GrpSts> ++ [0..1] TransactionGroup Status Code 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 PART - Partially accepted and rejected (detailed information on transaction level) RJCT - The whole message has been rejected StatusReasonInformation <StsRsnInf> ++ [0..n] StatusReason Information element 2.9 Reason <Rsn> +++ [0..1] StatusReason Choice element 2.10 {Or Code <Cd> ++++ [1..1] External Organisation Identification Code : maxlength: AdditionalInformation <AddtlInf> +++ [0..n] Max105Text maxlength: OriginalPaymentInformationAndStatus <OrgnlPmtInfAndSts> + [0..n] Original PaymentInform ation element C C M C 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. Must be present if code RJCT Specifies the reason for the status report 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>. Further details on the status reason. Usage: Additional information can be used for several purposes such as the reporting of repaired information. Bank specific codes may be used Information concerning the original payment information, to which the status report message refers.

16 6 237 A B C D E F H I J K ISO Or Message Item Tag Name Mult. Type Use Defenitions / Spesial comments Index Structural in IG No. Sequence 3.1 OriginalPaymentInformationIdentification <OrgnlPmtInfId> ++ [1..1] Max35Text maxlength: 35 minlength: 3.4 PaymentInformationStatus <PmtInfSts> ++ [0..1] TransactionGroup Status Code M C 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. ACWC accepted with change 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 StatusReasonInformation <StsRsnInf> ++ [0..n] StatusReason Information element 3.7 Reason <Rsn> +++ [0..1] StatusReason Choice element 3.8 {Or Code <Cd> ++++ [1..1] Externa lorganisation Identification Code : maxlength: AdditionalInformation <AddtlInf> +++ [0..n] Max105Text maxlength: NumberOfTransactionsPerStatus <NbOfTxsPerSts> ++ [0..n] NumberOf TransactionsPerSt atus3 element(s) C C M PDNG - Payment initiation or individual transaction included in the payment initiation is pending. Further checks and status update will be performed. 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 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] Max15 NumericText M Definition: Number of individual transactions contained in the message, detailed per status.

17 A B C D E F H I J K ISO Or Message Item Tag Name Mult. Type Use Defenitions / Spesial comments Index Structural in IG No. Sequence 3.13 DetailedStatus <DtldSts> +++ [1..1] TransactionIndivi dualstatus3code 3.14 DetailedControlSum <DtldCtrlSum> +++ [0..1] DecimalNumber fractiondigits: 17 totaldigits: TransactionInformationAndStatus <TxInfAndSts> ++ [0..n] Payment TransactionInfor mation25 element(s) 3.16 StatusIdentification <StsId> +++ [0..1] Max35Text maxlength: OriginalInstructionIdentification <OrgnlInstrId> +++ [0..1] Max35Text maxlength: OriginalEndToEndIdentification <OrgnlEndToEndId> +++ [0..1] Max35Text maxlength: TransactionStatus <TxSts> +++ [0..1] TransactionIndivi dualstatus3code M C R C 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. PDNG - Payment initiation or individual transaction included in the payment initiation is pending. Further checks and status update will be performed. Total of all individual amounts included in the message, irrespective of currencies, detailed per status. 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. Specifies the status of a transaction, in a coded form. When this message item is present, one of the following Status Code values must be used: ACCP - Accepted ACSC - Accepted Settlement Completed ACSP - Accepted Settlement In Process ACWC accepted with change PDNG - Pending further processing (lack of funding) RJCT - Rejected Payment initiation or individual transaction included in the payment initiation has been rejected.

18 6 298 A B C D E F H I J K ISO Or Message Item Tag Name Mult. Type Use Defenitions / Spesial comments Index Structural in IG No. Sequence 3.20 StatusReasonInformation <StsRsnInf> +++ [0..n] StatusReason Information8 element(s) 3.22 Reason <Rsn> ++++ [0..1] StatusReason6 Choice element(s) Specifies the reason for the status report {Or Code <Cd> [1..1] ExternalStatusRea son1code maxlength: AdditionalInformation <AddtlInf> ++++ [0..n] Max105Text maxlength: 105 M Most used codes are: (Telepay relaterte feilkoder) 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.

19 Change Control -- Customer Payment Status Report pain Change Date XML TAG Comments Change Request from Change Documented by 10-Sep-14 <GrpHdr><MsgId> Unique for each customer BSK-versj.ktrl Morten Holter 10-Sep-14 <GrpHdr><<SchemeName><Cd> Definitions: CUST is used to define sublevel id. BSK-versj.ktrl Morten Holter 10-Sep-14 <OrgnlGrpInfAndSts><GrpSts> Update on allowed codes BSK-versj.ktrl Morten Holter 10-Sep-14 <OrgnlGrpInfAndSts><StsRsnInf> Must be present if code RJCT BSK-versj.ktrl Morten Holter 10-Sep-14 <OrgnlGrpInfAndSts><StsRsnInf><Rsn> Use in IG changed to C BSK-versj.ktrl Morten Holter 10-Sep-14 <OrgnlPmtInfAndSts><PmtInfSts> Update on allowed codes BSK-versj.ktrl Morten Holter 10-Sep-14 <OrgnlPmtInfAndSts><NbOfTxsPerSts><DtldSts> Update on allowed codes BSK-versj.ktrl Morten Holter 10-Sep-14 <OrgnlPmtInfAndSts><TxInfAndSts><TxSts> Update on allowed codes BSK-versj.ktrl Morten Holter