BSK implementeringsguide ISO 20022 PAIN 001.001.03 ustomer redit Transfer Bankenes felles implementasjonsguide Basert på ommon Global Implementation GI" ommon Industry Agreement: As of October 14, 2010 APPOVED BY GI PLENAY: ay 11, 2011 januar 2012 BSK Bank IG ver 1 av pain 001.001.03 ustomer redit Transfer Initiation 201201 Side 1 av 45
Innhold Endringskatalog Dato Ver Utført av endringer 15.01.2012 1.0 orten Holter Første versjon. Innhold Side 1. 1.1 Innledning Funksjonell beskrivelse 3 4 1.1.1 1.1.2 Omfang av meldingssettet eldingsflyt 4 4 1.1.3 Betalingstyper 5 1.2 2. 2.1 2.2 2.3 Kvalitet Eksempler Enkel betaler debtor initiert T melding Betaling på grunnlag av mottatt faktura Papir eller efaktura Enkeltbetaling kontohaver initierer en betaling på vegne av 3.part. 5 6 6 7 8 2.4 På vegne av 3.part ved bruk av servicesenter 9 3. 3.1 Teknisk beskrivelse Bruk av melding 10 10 3.1.1 3.1.2 3.1.3 Identifikasjon av kunderoller Betalingsinformasjon yndighetsrapportering 10 10 11 3.2 eldingsoppbygging 11 4 Struktur 12 4.1 Forklaring til tabellene 12 4.1.2 Formatspesifikasjon 5. essage Functionality 12 14 5.1 Group Header 15 5.1.1 Information Structure Group Header 16 5 2 Payment Information 17 5.2.1 Information Structure Payment Information 18 5 3 redit Transfer Transaction Information 21 5.3.1 5.4 Information Structure redit Transfer Transaction Information Key s describing parties and instructions Descriptions. 25 30 5.4.1 Payment Information PaymentTypeInformation 30 5.4.2 Payment Information Debtor 31 5.4.3 Payment Information DebtorAccount 5.4.4 Payment Information DebtorAgent 5.4.5 Payment Information UltimateDebtor 5.4.6 redit Transfer Transaction Information PaymentIdentification 5.4.7 redit Transfer Transaction Information Amount 5.4.8 redit Transfer Transaction Information UltimateDebtor 5.4.9 redit Transfer Transaction Information IntermediaryAgent1 5.4.10 redit Transfer Transaction Information reditoragent 5.4.11 redit Transfer Transaction Information reditor 5.4.12 redit Transfer Transaction Information reditoraccount 5.4.13 redit Transfer Transaction Information Ultimatereditor 5.4.14 redit Transfer Transaction Information egulatoryeporting 5.4.15 redit Transfer Transaction Information emittanceinformation 31 32 33 34 35 36 37 38 39 41 42 43 44 BSK Bank IG ver 1 av pain 001.001.03 ustomer redit Transfer Initiation 201201 Side 2 av 45
1. Introduction 1. Innledning Implementasjonsguiden er utarbeidet i regi av BSK. Denne implementasjonsguiden for ustomerredittransfer melding er basert på ISO 20022 essage Definition eport (D) og ommon Global Implementation GI Guide for ISO 20022 ustomerredittransfer Initiation (T) of June 2011 Implementasjonsguiden beskriver hvordan XL ISO 20022 format skal benyttes for formidling av betalingsoppdrag inn mot norske er., og definerer hvilke informasjonser som må være med i et betalingsoppdrag, og som ene kan formidle videre til betalingsmottakers. Implementasjonsguiden kan også være til nytte i planlegging og oppbygging av EP - systemer som vil benytte xml-formater for utveksling av informasjon. ISO 20022 essage Definition eport (D) og essage Usage Guideline (UG) kan lastes ned fra: http://www.iso20022.org ommon Global Implementation initiative (ISO 20022 GI Initiative) er et "SWIFT comunity" hvis hovedoppgave er å definere én felles standard for implementering av ISO 20022 meldinger til bruk mellom er og enes bedriftskunder. GI Implementasjons IG av 13 juni 2011 er tilgjengelig på Swift omunity nets hjemmeside. https://www.swiftcommunity.net/communities/288/files ålgruppe ustomerredittransfer- meldingen er betalingsinstruksjoner til betalers som inneholder informasjon beregnet på de finansielle institusjonene som er involvert i betalingen, samt informasjon rettet til betalingsmottakeren. Første del av implementasjonsguiden gir en oversikt på generelt grunnlag om bruk av Tmeldinger, med fokus på funksjonalitet og omfang. Denne delen er på norsk eldingen skal nyttes av oppdragsgiver til å instruere betalers om å foreta en betalingsoverføring fra en angitt konto, samt gi grunnlag for å gi betalingsmottaker nødvendig informasjon om hva betalingen gjelder. Denne implementasjonsguiden gir flere eksempler på hvordan dette kan gjøres (se kapitlet eldingsflyt). 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. Denne delen er skrevet på engelsk, for å gjøre det enklere å samholde detaljinformasjon mellom ISO20022- D, GI-IG og BSK-IG, og se hvor det er lokalt avvik/presisering. BSK Bank IG ver 1 av pain 001.001.03 ustomer redit Transfer Initiation 201201 Side 3 av 45
1. Introduction 1.1 Funksjonell beskrivelse T-meldingen inneholder all den informasjonen de finansielle institusjonene trenger for å utføre en betaling. En T melding gir finansinstitusjonen en instruks om å overføre et bestemt beløp i en spesifisert valuta fra en bestemt konto til en bestemt mottakskonto. Det er mulig å overføre flere slike bestillinger i den samme meldingen. T-meldingen kan inneholde nødvendig informasjon som gir betalingsmottakeren mulighet til enkelt å matche inngående betalinger mot, for eksempel, utestående kundefordringer eget system, ved at Fakturanummer, eller KID kan følge med som strukturert informasjon. - En T-melding kan referere til en eller flere fakturaer og kreditt notater, eller andre grunner for betaling. 1.1.1 Omfang av meldingssettet T-meldinger utveksles mellom en oppdragsgiver Initiating Party (InitiatingParty) og betalers Debtor Agent (DebtorAgent) eventuelt via en formidler (ForwardingAgent eldingssettet dekker betalers behov for å initiere betalinger, overvåke og administrere de. eldingstypene er: ustomerredittransferinitiationv03: brukes til å initiere et betalingsoppdrag. Den sendes fra betaler til betalers, eventuelt via en formidler. ustomerpaymentstatuseportv03: brukes til å rapportere status på betalingsoppdraget. Den blir sendt fra betalers eller via formidler tilbake til betaler. Bruk av denne meldingstypen avtales mellom betaler og /formidler. ustomerpaymentancelationequestv01: brukes til å sende en stoppordre på et tidligere innsendt betalingsoppdrag. Den sendes fra betaler til betalers, eventuelt via en formidler. Bruk av denne meldingstypen avtales mellom betaler og /formidler. Denne implementasjonsguide dekker ustomer redit TransferInitiation V03. 1.1.2 eldingsflyt T-meldingen sendes fra Oppdragsgiver/betaler (InitiatingParty) til betalers (Debtor Agent), eventuelt via en formidler (ForwardingAgent). Scenariene som er beskrevet,viser forskjellige kunderoller på betalersiden av et betalingsoppdrag, og tilsvarende på betalingsmottakersiden. På oppdragssiden, kan inntil tre roller spesifiseres: InitiatingParty, dvs. den som sender meldingen, Debtor, dvs. eier av konto som skal belastes, og UltimateDebtor, dvs. den som skylder penger til kreditor som følge av mottak av varer eller tjenester. Disse tre rollene kan dekkes av én og samme aktør, eller de kan dekkes av ulike aktører. T-meldingen gjør det mulig å inkludere alle tre roller i en melding. På betalingsmottakssiden, kan inntil to roller spesifiseres: reditor, dvs. eieren av kontoen som skal godskrives, og Ultimatereditor, dvs. den som er fordringshaver / den som skal motta pengene. Disse to rollene kan dekkes av én og samme aktør, eller de kan dekkes av ulike aktører. T-meldingen gjør det mulig å inkludere begge roller i en melding. BSK Bank IG ver 1 av pain 001.001.03 ustomer redit Transfer Initiation 201201 Side 4 av 45
1. Introduction 1.1.3 Betalingstyper T-meldinger vil i hovedsak bli brukt for å dekke innenlandske- og grensekryssende betalinger: Betalingsinstruksjonen dekker informasjonsbehovet ved betaling av en eller flere fakturaer hvor det skal være en spesifikasjon i form av en referanse m.m. til underliggende handelstransaksjon. asseutbetalinger omfatter normalt lønns- eller pensjonsutbetalinger eller 1 til mange regningsbetalinger. 1.2 Kvalitet I forbindelse med elektronisk utveksling av meldinger, vil meldingene bli lest maskinelt av system hos mottaker av meldingen. an bør derfor legge opp til strenge rutiner rundt meldingsutveksling, herunder bl.a.: - Nummerering av meldinger for å sikre at meldinger ikke går tapt under overføring - utiner for å sikre at meldinger ikke sendes flere ganger - Sikre at meldingsinnhold ikke kan manipuleres under overføring - Sikre at avsender faktisk er den han gir seg ut for å være - Sikre at meldingen inneholder tilstrekkelig informasjon for ende til ende betaling - Sikre at informasjon i meldingen ikke kan leses av uvedkommende - Statusrapport fra bekrefter at har overtatt ansvar Ovennevnte går i stor grad på forhold rundt utveksling av meldinger og dekkes ikke av denne IG. Krav til utveksling avtales med den enkelte. BSK Bank IG ver 1 av pain 001.001.03 ustomer redit Transfer Initiation 201201 Side 5 av 45
2. Eksempel 2. Eksempler på bruk av ustomerredittransfer-meldinger 2.1 Enkel betaling (debtor) initiert T-melding I dette eksemplet er det kontoeier (Debtor) som initierer betalingsoppdraget. Betalers konto er i Bank A (DebtorAgent). Betalingsmottaker (reditor) har sin konto i Bank B (reditoragent). (Eksempelvis lønn, pensjon) Betaler genererer i sitt system en T-melding som sendes til betalers (Bank B) med instruksjon om overføring av beløp til kreditors konto i Bank B. Betaling utføres, og transaksjon med informasjon fra T-melding sendes B for godskrift av kreditors konto og utsending av informasjon om kreditering til betalingsmottaker. BSK Bank IG ver 1 av pain 001.001.03 ustomer redit Transfer Initiation 201201 Side 6 av 45
2. Eksempel 2.2 Betaling på grunnlag av mottatt faktura Papir eller efaktura) Kreditor sender faktura til Betaler på papir eller som efaktura (avhengig av betaler kan motta efaktura. Hvis efaktura går den via Access punkt som videreformidler til betaler. Betaler mottar efaktura og leser denne inn i sitt EP system. Tilrettelagt for elektronisk fakturahåndtering. Autorisert efaktura vil generere en T-melding med informasjon fra efakturaen. Denne sendes til Bank A som betalingsinstruksjon. Betaling utføres, og transaksjon med informasjon fra T-melding sendes B for godskrift av kreditors konto og utsending av informasjon om kreditering til betalingsmottaker. BSK Bank IG ver 1 av pain 001.001.03 ustomer redit Transfer Initiation 201201 Side 7 av 45
2. Eksempel 2.3 Enkeltbetaling kontohaver initierer en betaling på vegne av 3.part. I dette eksemplet har vi tatt utgangspunkt i et konsern, hvor mor er kontoeier, også for alle datterselskap. or initierer betalingsoppdrag på vegne av et datterselskap som er skyldner, og mottaker av faktura. På fakturautsteder siden har vi en tilsvarende konstellasjon, hvor mor er eier av kreditkonto oppgitt i fakturaen, men hvor datterselskap er den egentlige fordringshaver. BSK Bank IG ver 1 av pain 001.001.03 ustomer redit Transfer Initiation 201201 Side 8 av 45
2. Eksempel 2.4 På vegne av 3.part ved bruk av servicesenter I dette eksemplet er Kunde A både kontohaver og skyldner (mottaker av faktura), så derfor er det kun nødvendig å angi Betaler (Debtor) rollen i meldingen. Kunde a benytter seg av et SharedServiceenter (SS), som f.eks kan være et regnskapskontor, for å foreta betalinger. Siden SS kun opererer på vegne av Kunde A, vil SS kun være en operatør som lager meldingen, og fungere som en Gateway for Kunde A for elektronisk utveksling mot en. SS trenger derfor ikke å være identifisert i T-meldingen. BSK Bank IG ver 1 av pain 001.001.03 ustomer redit Transfer Initiation 201201 Side 9 av 45
3. Teknisk beskrivelse 3. Teknisk beskrivelse elding Pain.001.001.03 ustomerredittransferinitiation V03 3.1 Bruk av melding T-meldingen kan benyttes både for innlandsbetalinger og for grensekryssende betalinger. T-meldingen identifiseres i xml-skjemaet på følgende måte: urn: iso: std: iso: 20022: tech: xsd: pain.001.001.03 En T-melding kan inneholde: - En eller flere betalingsoppdrag - Et betalingsoppdrag kan inneholde en eller flere betalingstransaksjoner - En betalingstransaksjon kan resulterer i en kontooverføring eller utstedelse av anvisning / Sjekk. eldingen kan benyttes til enkeltbetalinger, da vil Paymentinformation -komponenten gjentas pr redit transaction -komponent. eldingen kan også brukes til å gruppere betalinger, da vil Payment information -komponenten (debitsiden) forekomme en gang, med flere etterfølgende redittrasnfertransactioninformation (kreditsiden). For innenlandsbetalinger vil det da normalt genereres en sumpost på betalers konto. For grensekryssende betalinger vil det være avhengig a v den enkelte s tjenester og bokføringsprinsipper. 3.1.1 Identifikasjon av kunderoller I T-meldingen kan man angi flere kunderoller. På oppdragssiden, kan inntil tre roller spesifiseres: Initiating Party, dvs. den som sender meldingen, Debtor, dvs. eier av konto som skal belastes, og UltimateDebtor, dvs. den som skylder penger til kreditor som følge av mottak av varer eller tjenester. Disse tre rollene kan dekkes av én og samme aktør, eller de kan dekkes av ulike aktører.oppbyggingen av T-meldingen gjør det mulig å inkludere alle tre roller i en melding. På betlingsmottakssiden, kan inntil to roller spesifiseres: reditor, dvs. eieren av kontoen som skal godskrives, og Ultimatereditor, dvs. den som er fordringshaver / den som skal motta pengene. Disse to rollene kan dekkes av én og samme aktør, eller de kan dekkes av ulike aktører. Oppbyggingen av Tmeldingen gjør det mulig å inkludere begge roller i en melding. 3.1.2 Betalingsinformasjon T-meldingen kan inneholde grunnleggende betalingsinformasjon. Den kan også inneholde strukturert referanseinformasjon som henviser til betalingsinformasjon som er sendt separat fra betaler. BSK Bank IG ver 1 av pain 001.001.03 ustomer redit Transfer Initiation 201201 Side 10 av 45
3. Teknisk beskrivelse 3.1.3 yndighetsrapportering For betalingstyper som krever spesiell myndighetsrapportering, gir T-meldinger mulighet for å angi nødvendig informasjon i tilknytning til transaksjoner hvor rapportering er nødvendig. 3.2 eldingsoppbygging T-melding basert på ISO20022 PAIN.001.001.03 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 001.001.03 ustomer redit Transfer Initiation 201201 Side 11 av 45
4. Struktur 4 Struktur 4.1 Forklaring til tabellene GENEELLE PINSIPPE FO TABELLEN SO E BENYTTET FO Å BESKIVE FOAT OG STUKTU FO T-ELDING Alle er som må være med (andatory) i ISO20022. PAIN 001.001.03, er med i den norske IG, det samme gjelder for er 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 20022 essage Definition eport eller i GI Implementation Guide for ISO 20022 ustomerredittransfer Initiation. Dette er gjort for å forenkle bruken IG 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, må dette avtales med. ISO Index eferansenummer som henviser til relatert feltbeskrivelse i ISO 20022 essage Definition eport essage Item refererer til det faktiske tagnavn i XL. Som angis i kolonnen XL Tag Name. Det kan være et eldings (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 meldings). Hvert meldings komplementeres med hva slags type det er (angis i kolonnen Type). Tag Name, Den spesifikke koden knyttet til et XL-, og som vil inngå i XL Schema for å identifisere et XL-. Tag Name vil starte strengen med informasjon som skal inngå i et (f.eks. <Dbtr>) og strengen avsluttes med den samme tagen med en forutgående slash (f.eks. </Dbtr>). Structural : Angir hvor i meldingsstrukturen et er plassert BSK Bank IG ver 1 av pain 001.001.03 ustomer redit Transfer Initiation 201201 Side 12 av 45
4. Struktur ultiplicity, angir hvor mange ganger et et kan/skal være med. ax antall styres avrammene i NIBE-formatet. Type, angir den type verdi som skal overføres for det aktuelle et i XL-notasjon. Det er 7 forskjellige Data Type representasjoner som kan benyttesi en T-melding: Identifier, ode, Text, ate, Date Time, Amount, Indicator. Use in IG, Her angir BSK klassifisering som er fastsatt i BSK T-melding IG. ISO 20022 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 et, regler for utfylling, lovlige verdier mm, i henhold til ISO 20022 I kursiv vil det stå forklaringer på bruken av et i det norske markedet BSK Bank IG ver 1 av pain 001.001.03 ustomer redit Transfer Initiation 201201 Side 13 av 45
5. essage Functionality 5. essage Functionality The message starts with the 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.001.001.03 This message is built up by three building blocks: GroupHeader, PaymentInformation and redittransfertransactioninformation. BSK Bank IG ver 1 av pain 001.001.03 ustomer redit Transfer Initiation 201201 Side 14 av 45
5.1 Group Header 5.1 Group Header This building block is mandatory and present once. It contains s such as essageidentification, reationdateandtime, Grouping indicator. And identifies the initiator of the message. Elements presented in this figure is the s used in the Norwegian IG. BSK Bank IG ver 1 av pain 001.001.03 ustomer redit Transfer Initiation 201201 Side 15 av 45
5.1.1 Information Structure 5.1.1 Information Structure Group Header ISO Index Or essage Item Tag Name Structural ult. Type Use in IG Defenitions / Spesial comments <stmrdttrfinitn> - essage root, identifying message type 1.0 GroupHeader <GrpHdr> + [1..1] Set of characteristics shared by all individual transactions included in the message. 1.1 essageidentification <sgid> ++ [1..1] ax 35 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. Unique for each customer min. 3 month Will be used in status reports (PS) initiated by this message 1.2 reationdatetime <redttm> ++ [1..1] DateTime Date and time at which the message was created. 1.6 NumberOfTransaction s <NbOfTxs> ++ [1..1] ax15 Numeric Text 1.7 ontrolsum <trlsum> ++ [0..1] Decimal Number BD Number of individual transactions contained in the message. Total of all individual amounts included in the message, irrespective of currencies. 1.8 InitiatingParty <InitgPty> ++ [1..1] Party Identification 32 omponent 9.1.0 Name <Nm> +++ [0..1] ax 140 Text 9.1.12 Identification <Id> +++ [0..1] hoice omponenet 9.1.13 {Or OrganisationIdentificat ion <OrgId> ++++ [1..1] Organisation Identification 4 To be agreed with the debtors Party that initiates the payment. This can either be the debtor or the party that initiates the credit transfer on behalf of the debtor Name by which a party is known and which is usually used to identify that party. Unique and unambiguous identification of a party. Unique and unambiguous way to identify an organisation. 9.1.14 BIOrBEI <BIOrBEI> +++++ [0..1] AnyBI Identifier BD ode allocated to organisations by the ISO 9362 egistration Authority, under an international identification scheme, as described in the latest version of the standard ISO 9362 Banking (Banking telecommunication messages, Bank Identifier odes). Only a valid BI or BEI is allowed. Valid BEI and BI are registered with the ISO 9362 egistration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK ODE, OUNTY ODE, LOATION ODE, BANH ODE. The code, country code and location code are mandatory, while the branch code is optional. 9.1.15 Other <Othr> +++++ [0..n] Organisation Identification 1 BD Unique identification of an organisation, as assigned by an institution, using an identification scheme. 9.1.16 Identification <Id> ++++++ [1..1] Text ax35 Identification assigned by an institution. In Norway this may be the customer-id in the debtor, which may be based on Brønnøysundregistrene and their entral oordinating egister of Legal Entities, or another identification agreed with the 9.1.17 SchemeName <SchmeNm> ++++++ [0..n] rganisationid entificationsc hemename1 hoice BD Name of the identification scheme. 9.1.18 ode <d> +++++++ [1..1] ode BANK = Agreement-id UST = Sublevel-id customer This message item is part of choice 9.1.17 SchemeName BSK Bank IG ver 1 av pain 001.001.03 ustomer redit Transfer Initiation 201201 Side 16 av 45
5.2 Payment Information 5,2 Payment Information This building block is mandatory and repetitive. It contains, s related to the debit side of the transaction. BSK Bank IG ver 1 av pain 001.001.03 ustomer redit Transfer Initiation 201201 Side 17 av 45
5.2.1 Information Structure 5.2.1 Information Structure Payment Information ISO Index Or essage Item Tag Name Structural ult. Type Use in IG Defenitions / Spesial comments 2.0 PaymentInformation <PmtInf> + [1..n] Set of characteristics that applies to the debit side of the payment transactions included in the credit transfer initiation 2.1 PaymentInformationIdentification <PmtInfId> ++ [1..1] ax35text Unique identification, as assigned by a sending party, to unambiguously identify the payment information group within the message. Unique for each customer min. 3 month 2.2 Paymentethod <Pmttd> ++ [1..1] ode Specifies the means of payment that will be used to move the amount of money. 2.3 BatchBooking <BtchBookg> ++ [0..1] Batch Booking Indicator BD Identifies whether a single entry per individual transaction or a batch entry for the sum of the amounts of all transactions within the group of a message is requested. Usage: Batch booking is used to request and not order a possible batch booking. If used: True : Identifies that a batch entry for the sum of the amounts of all transactions in the message is requested. False: Identifies that a single entry for each of the transactions in the message is requested. 2.5 ontrolsum <trlsum> ++ [0..1] Decimal Number fraction Digits: 17 total Digits: 18 BD General definition: Total of all individual amounts included in the group, irrespective of currencies. In Norway: All individual amounts must be in the same currency 2.6 PaymentTypeInformation <PmtTpInf> ++ [0..1] Payment Type Information 19 Set of s used to further specify the type of transaction. equired at either Payment or Transaction Level, but should not be present at both levels. ecommnded usage is at Payment level. 2.7 InstructionPriority <InstrPrty> +++ [0..1] ode BD Based on whether priority processing vs. normal processing is offered by the. Valid codes: HIGH - High priority processing NO - Normal processing 2.8 ServiceLevel <SvcLvl> +++ [0..1] Service Level8 hoice Agreement/rule under which the transaction should be processed. 2.9 {Or ode <d> ++++ [1..1] ode maxlength: 4 Specifies a pre-agreed service or level of service between the parties, as published in an external service level code list. 2.14 ategorypurpose <tgypurp> +++ [0..1] ategorypurpose1 hoice Specifies the high level purpose of the instruction based on a set of pre-defined categories. Usage: This is used by the initiating party to provide information concerning the processing of the payment. It is likely to trigger special processing by any of the agents involved in the payment chain. In absence of this, the payment will be prosessed as a supplier payment 2.15 {Or ode <d> ++++ [1..1] Externalategory Purpose1 ode maxlength: 4 Specifies the high level purpose of the instruction based on a set of pre-defined categories. Usage: This is used by the initiating party to provide information concerning the processing of the payment. It is likely to trigger special processing by any of the agents involved in the payment chain. Valid codes example: INT, PENS, SALA, SUPP, TEA 2.17 equestedexecutiondate <eqdexctndt> ++ [1..1] DateTime Date at which the initiating party requests the clearing agent to process the payment. Usage: This is the date on which the debtor's account is to be debited. If payment by cheque, the date when the cheque must be generated by the. 2.19 Debtor <Dbtr> ++ [1..1] PartyIdentification32 Party that owes an amount of money to the (ultimate) creditor. This is the owner of the debtor account 9.1.12 Identification <Id> +++ [0..1] Party6hoice Unique and unambiguous identification of a party. 9.1.13 {Or OrganisationIdentification <OrgId> ++++ [1..1] Organisation Identification4 Unique and unambiguous way to identify an organisation. BSK Bank IG ver 1 av pain 001.001.03 ustomer redit Transfer Initiation 201201 Side 18 av 45
5.2.1 Information Structure ISO Index Or essage Item Tag Name Structural ult. Type Use in IG Defenitions / Spesial comments 9.1.14 BIOrBEI <BIOrBEI> +++++ [0..1] AnyBIIdentifier BD ode allocated to organisations by the ISO 9362 egistration Authority, under an international identification scheme, as described in the latest version of the standard ISO 9362 Banking (Banking telecommunication messages, Bank Identifier odes). In Norway: Only a valid BI or BEI is allowed. Valid BEI and BI are registered with the ISO 9362 egistration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK ODE, OUNTY ODE, LOATION ODE, BANH ODE. The code, country code and location code are mandatory, while the branch code is optional. 9.1.15 Other <Othr> +++++ [0..n] GenericOrganisation Identification1 BD Unique identification of an organisation, as assigned by an institution, using an identification scheme. 9.1.16 Identification <Id> ++++++ [1..1] ax35text Identification assigned by an institution. Organisation number 2.20 DebtorAccount <DbtrAcct> ++ [1..1] ashaccount16 Unambiguous identification of the account of the debtor to which a debit entry will be made as a result of the transaction. 1.1.0 Identification <Id> +++ [1..1] AccountIdentification4 hoice 1.1.1 {Or IBAN <IBAN> ++++ [1..1] IBAN2007Identifier Format: [A-Z]{2,2}[0-9]{2,2}[a-zA-Z0-9]{1,30} 1.1.2 Or} Other <Othr> ++++ [1..1] GenericAccount Identification1 1.1.3 Identification <Id> +++++ [1..1] ax34text maxlength: 34 1.1.4 SchemeName <SchmeNm> +++++ [0..1] AccountSchemeName1 hoice 1.1.5 {{Or ode <d> ++++++ [1..1] ExternalAccount Identification1ode maxlength: 4 2.21 DebtorAgent <DbtrAgt> ++ [1..1] BranchAndFinancialInstitu tionidentification4 BD Unique and unambiguous identification for the account between the account owner and the account servicer. International Bank Account Number (IBAN) - identifier used internationally by financial institutions to uniquely identify the account of a customer. Further specifications of the format and content of the IBAN can be found in the standard ISO 13616 "Banking and related financial services - International Bank Account Number (IBAN)" version 1997-10-01, or later revisions. A valid IBAN consists of all three of the following components: ountry ode, check digits and BBAN. Unique identification of an account, as assigned by the account servicer, using an identification scheme. Identification assigned by an institution. Local accountnumber that will be debited for the transactions Name of the identification scheme Name of the identification scheme, in a coded form as published in an external list. Valid code: BBAN Financial institution servicing an account for the debtor. 6.1.0 FinancialInstitutionIdentification <FinInstnId> +++ [1..1] FinancialInstitution Identification7 Unique and unambiguous identification of a financial institution, as assigned under an internationally recognised or proprietary identification scheme. 6.1.1 BI <BI> ++++ [0..1] BI Identifier Bank Identifier ode. ode allocated to financial institutions by the egistration Authority, under an international identification scheme, as described in the latest version of the standard ISO 9362 Banking (Banking telecommunication messages, Bank Identifier odes). Valid BIs are registered with the ISO 9362 egistration Authority, and consist of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK ODE, OUNTY ODE, LOATION ODE, BANH ODE. The code, country code and location code are mandatory, while the branch code is optional. 2.23 UltimateDebtor <UltmtDbtr> ++ [0..1] PartyIdentification32 9.1.0 Name <Nm> +++ [0..1] ax140text maxlength: 140 Ultimate party that owes an amount of money to the (ultimate) creditor. Name by which a party is known and which is usually used to identify that party. In Norway, field length restrictions may apply, contact your 9.1.1 PostalAddress <PstlAdr> +++ [0..1] PostalAddress6 Information that locates and identifies a specific address, as defined by postal services. Use of structured address is recommended. 9.1.5 StreetName <StrtNm> ++++ [0..1] ax70text maxlength: 70 9.1.7 Postode <Pstd> ++++ [0..1] ax16text maxlength: 16 Name of a street or thoroughfare. Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting. BSK Bank IG ver 1 av pain 001.001.03 ustomer redit Transfer Initiation 201201 Side 19 av 45
5.2.1 Information Structure ISO Index Or essage Item Tag Name Structural ult. Type Use in IG Defenitions / Spesial comments 9.1.8 TownName <TwnNm> ++++ [0..1] ax16text maxlength: 16 9.1.10 ountry <try> ++++ [0..1] ountryode Format: [A-Z]{2,2} Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting of mail. Nation with its own government. 9.1.11 AddressLine <AdrLine> ++++ [0..7] ax70text maxlength: 70 Information that locates and identifies a specific address, as defined by postal services, presented in free format text. In Norway, Field length restrictions may apply, contact your 2.24 hargebearer <hrgbr> ++ [0..1] hargebearertype1 ode BD Specifies which party/parties will bear the charges associated with the processing of the payment transaction. Domestic payments SHA; SEPA payments SLEV; ross Border payments DEBT, ED, SHA, onditional based on wether used on payment- and crdittrasaction level. In absence of this, the will handle this as a payment where each party pays their own cost. BSK Bank IG ver 1 av pain 001.001.03 ustomer redit Transfer Initiation 201201 Side 20 av 45
5.3 redit Transfer Transaction 5.3 redit Transfer Transaction Information This building block is mandatory and repetitive,. It contains, s related to the credit side of the transaction BSK Bank IG ver 1 av pain 001.001.03 ustomer redit Transfer Initiation 201201 Side 21 av 45
5.3 redit Transfer Transaction BSK Bank IG ver 1 av pain 001.001.03 ustomer redit Transfer Initiation 201201 Side 22 av 45
5.3 redit Transfer Transaction BSK Bank IG ver 1 av pain 001.001.03 ustomer redit Transfer Initiation 201201 Side 23 av 45
5.3.1 Information Structure 5.3.1 Information Structure redit Transfer Transaction Information ISO Index Or essage Item Tag Name Structural ult. Type Use in IG Defenitions / Spesial comments 2.27 redittransfertransactioninformation <dttrftxinf> ++ [1..n] Set of s used to provide information on the individual credit transfer transaction(s) included in the message. 2.28 PaymentIdentification <PmtId> +++ [1..1] Payment Identification1 Set of s used to reference a payment instruction. 2.29 InstructionIdentification <InstrId> ++++ [0..1] ax35text BD Unique identification as assigned by an instructing party for an instructed party to unambiguously identify the instruction. Unique for each customer, minmum 3 months. 2.30 EndToEndIdentification <EndToEndId> ++++ [1..1] ax35text 2.31 PaymentTypeInformation <PmtTpInf> +++ [0..1] PaymentType Information19 Unique identification assigned by the initiating party to unumbiguously identify the transaction. This identification is passed on, unchanged, throughout the entire end-to-end chain. Unique for each customer minimum 3 months. Set of s used to further specify the type of transaction. ay be used either on this level or the Payment Information Level 2.32 InstructionPriority <InstrPrty> ++++ [0..1] Priority2ode BD Based on whether priority processing vs. normal processing is offered by the. Valid codes: HIGH - High priority processing NO - Normal processing 2.33 ServiceLevel <SvcLvl> ++++ [0..1] ServiceLevel8 hoice 2.34 {Or ode <d> +++++ [1..1] ExternalServiceLeve l1ode maxlength: 4 2.39 ategorypurpose <tgypurp> ++++ [0..1] ategory Purpose1hoice 2.40 {Or ode <d> +++++ [1..1] ExternalategoryPu rpose1ode maxlength: 4 Agreement under which or rules under which the transaction should be processed. Specifies a pre-agreed service or level of service between the parties, as published in an external service level code list. ontact the financial institution for information Specifies the high level purpose of the instruction based on a set of pre-defined categories. Usage: This is used by the initiating party to provide information concerning the processing of the payment. It is likely to trigger special processing by any of the agents involved in the payment chain. In absence of this, the payment will be prosessed as a supplier payment ategory purpose, as published in an external category purpose code list. Valid codes excamples: INT, PENS, SALA, SUPP, TEA 2.42 Amount <Amt> +++ [1..1] AmountType3 hoice Amount of money to be moved between the debtor and creditor, before deduction of charges, expressed in the currency as ordered by the initiating party. 2.43 {Or InstructedAmount <InstdAmt cy="aaa"> ++++ [1..1] ActiveOrHistoricu rrencyode fractiondigits: 5 mininclusive: 0 totaldigits: 18 Amount of money to be moved between the debtor and creditor, before deduction of charges, expressed in the currency as ordered by the initiating party. 2.44 Or} EquivalentAmount <EqvtAmt> ++++ [1..1] Equivalent Amount2 Amount of money to be moved between the debtor and creditor, expressed in the currency of the debtor's account, and the currency in which the amount is to be moved. 2.45 Amount <Amt cy="aaa"> +++++ [1..1] ActiveOrHistoricu rrencyode fractiondigits: 5 mininclusive: 0 totaldigits: 18 2.46 urrencyoftransfer <cyoftrf> +++++ [1..1] ActiveOrHistoricu rrencyode Amount of money to be moved between debtor and creditor, before deduction of charges, expressed in the currency of the debtor's account, and to be moved in a different currency. Usage: The first agent will convert the equivalent amount into the amount to be moved. Specifies the currency of the to be transferred amount, which is different from the currency of the debtor's account. The urrency ode must be registered, or have already been registered. Valid active or historic currency codes are registered with ISO 4217 2.47 ExchangeateInformation <XchgateInf> +++ [0..1] Exchangeate Information1 BD Set of s used to provide details on the currency exchange rate and contract. 2.48 Exchangeate <Xchgate> ++++ [0..1] BaseOneate fractiondigits: 10 totaldigits: 11 The factor used for conversion of an amount from one currency to another. This reflects the price at which one currency was bought with another currency. BSK Bank IG ver 1 av pain 001.001.03 ustomer redit Transfer Initiation 201201 S24 av 45
5.3.1 Information Structure ISO Index Or essage Item Tag Name Structural ult. Type Use in IG 2.49 atetype <atetp> ++++ [0..1] Exchangeate Type1ode Defenitions / Spesial comments Specifies the type used to complete the currency exchange AGD - Exhange rate applied is the rate agreed between the parties SALE - Exchange rate applied is the market rate at time of the sale SPOT - Exchange rate applied is the spot rate 2.50 ontractidentification <trctid> ++++ [0..1] ax35text Unique and unambiguous reference to the foreign exchange contract agreed between the initiating party/ creditor and the debtor agent. 2.51 hargebearer <hrgbr> +++ [0..1] hargebearer Type1ode BD Specifies which party/parties will bear the charges associated with the processing of the payment transaction. Domestic payments - SHA SEPA payments - SLEV ross Border payments - DEBT, ED, SHA, SLEV onditional based on wether used on payment- og crdittrasaction level. In absence of this, the will handle this as a payment where each party pays their own cost.. 2.52 hequeinstruction <hqinstr> +++ [0..1] heque6 BD Set of s needed to issue a cheque. 2.53 hequetype <hqtp> ++++ [0..1] hequetype2 ode BD Specifies the type of cheque to be issued. Valid codes: BHQ - heque drawn on the account of the debtor's financial institution. The financial institution prints and certifies the cheque, guaranteeing the payment. Synonym is 'cashier's cheque'. 2.58 Deliveryethod <Dlvrytd> ++++ [0..1] heque Deliveryethod1 hoice 2.59 {Or ode <d> +++++ [1..1] hequedelivery1o de BD Specifies the delivery method of the cheque by the debtor's agent. Specifies the delivery method of the cheque by the debtor's agent. Valid codes: LDB - heque is to be sent through mail services to debtor. PUDB - heque will be picked up by the debtor. 2.70 UltimateDebtor <UltmtDbtr> +++ [0..1] Party Identification32 9.1.0 Name <Nm> ++++ [0..1] ax140text maxlength: 140 9.1.1 PostalAddress <PstlAdr> ++++ [0..1] PostalAddress6 9.1.5 StreetName <StrtNm> +++++ [0..1] ax70text maxlength: 70 9.1.7 Postode <Pstd> +++++ [0..1] ax16text maxlength: 16 9.1.8 TownName <TwnNm> +++++ [0..1] ax35text Ultimate party that owes an amount of money to the (ultimate) creditor. Name by which a party is known and which is usually used to identify that party. Information that locates and identifies a specific address, as defined by postal services. Use of structured address is recommended. Name of a street or thoroughfare. Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting of mail. 9.1.10 ountry <try> +++++ [0..1] ountryode Nation with its own government. The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code). 9.1.11 AddressLine <AdrLine> +++++ [0..7] ax70text maxlength: 70 Information that locates and identifies a specific address, as defined by postal services, presented in free format text. 2.71 IntermediaryAgent1 <IntrmyAgt1> +++ [0..1] BranchAnd Financial Institution Identification4 BD Agent between the debtor's agent and the creditor's agent. For Norway only one intermediary agent is present, Used only if reditor Agent has instructed that the payment should pass their agent. 6.1.0 FinancialInstitutionIdentification <FinInstnId> ++++ [1..1] Financial Institution Identification7 Unique and unambiguous identification of a financial institution, as assigned under an internationally recognised or proprietary identification scheme. BSK Bank IG ver 1 av pain 001.001.03 ustomer redit Transfer Initiation 201201 S25 av 45
5.3.1 Information Structure ISO Index Or essage Item Tag Name Structural ult. Type Use in IG Defenitions / Spesial comments 6.1.1 BI <BI> +++++ [0..1] BI Identifier Bank Identifier ode. ode allocated to financial institutions by the egistration Authority, under an international identification scheme, as described in the latest version of the standard ISO 9362 Banking (Banking telecommunication messages, Bank Identifier odes). Valid BIs are registered with the ISO 9362 egistration Authority, and consist of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK ODE, OUNTY ODE, LOATION ODE, BANH ODE. The code, country code and location code are mandatory, while the branch code is optional. 2,77 reditoragent <dtragt> +++ [0..1] BranchAnd Financial Institution Identification Financial institution servicing an account for the creditor. equired in ross Border Payments and SEPA Payments 6.1.0 FinancialInstitutionIdentification <FinInstnId> ++++ [1..1] 6.1.1 BI <BI> +++++ [0..1] BI Identifier Bank Identifier ode. ode allocated to financial institutions by the egistration Authority, under an international identification scheme, as described in the latest version of the standard ISO 9362 Banking (Banking telecommunication messages, Bank Identifier odes). Valid BIs are registered with the ISO 9362 egistration Authority, and consist of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK ODE, OUNTY ODE, LOATION ODE, BANH ODE. The code, country code and location code are mandatory, while the branch code is optional. 6.1.2 learingsystememberidentification <lrsysmbid> +++++ [0..1] learingsystem ember Identification 6.1.3 learingsystemidentification <lrsysid> ++++++ [0..1] learingsystem Identification hoice 6.1.4 {Or ode <d> +++++++ [1..1] Externallearing System Identification1 ode maxlength: 5 Information used to identify a member within a clearing system. Specification of a pre-agreed offering between clearing agents or the channel through which the payment instruction is processed. Identification of a clearing system, in a coded form as published in an external list. This message item is part of choice 6.1.3 learingsystemidentification. 6.1.6 emberidentification <mbid> ++++++ [1..1] ax35text 6.1.7 Name <Nm> +++++ [0..1] ax140text maxlength: 140 6.1.8 PostalAddress <PstlAdr> +++++ [0..1] PostalAddress6 6.1.12 StreetName <StrtNm> ++++++ [0..1] ax70text maxlength: 70 6.1.14 Postode <Pstd> ++++++ [0..1] ax16text maxlength: 16 6.1.15 TownName <TwnNm> ++++++ [0..1] ax35text Identification of a member of a clearing system. Name by which an agent is known and which is usually used to identify that agent. Information that locates and identifies a specific address, as defined by postal services. Name of a street or thoroughfare. Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting of mail. Name of a built-up area, with defined boundaries, and a local government. 6.1.17 ountry <try> ++++++ [0..1] ountryode Nation with its own government. The code is checked against the list of country names obtained from the United Nations (ISO 3166, 6.1.18 AddressLine <AdrLine> ++++++ [0..7] ax70text maxlength: 70 2.79 reditor <dtr> +++ [0..1] PartyIdentification32 9.1.0 Name <Nm> ++++ [0..1] ax140text maxlength: 140 Information that locates and identifies a specific address, as defined by postal services, presented in free format text. Party to which an amount of money is due. equired in ross Border Payments and SEPA Payments For Norwegian domestic payments, except money orders, only credit account is needed. reditoragent is required to forward information related to the payment, and uses reditor Adress information connected to the reditaccount in their own system. Name by which a party is known and which is usually used to identify that party. BSK Bank IG ver 1 av pain 001.001.03 ustomer redit Transfer Initiation 201201 S26 av 45
5.3.1 Information Structure ISO Index Or essage Item Tag Name Structural ult. Type Use in IG 9.1.1 PostalAddress <PstlAdr> ++++ [0..1] PostalAddress6 9.1.5 StreetName <StrtNm> +++++ [0..1] ax70text maxlength: 70 Defenitions / Spesial comments Information that locates and identifies a specific address, as defined by postal services. Use of structured address is recommended. equired for cross border payments Name of a street or thoroughfare. 9.1.7 Postode <Pstd> +++++ [0..1] ax16text maxlength: 16 9.1.8 TownName <TwnNm> +++++ [0..1] ax35text Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting of mail. Name of a built-up area, with defined boundaries, and a local government. 9.1.10 ountry <try> +++++ [0..1] ountryode Nation with its own government. The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code). 9.1.11 AddressLine <AdrLine> +++++ [0..7] ax70text maxlength: 70 9.1.12 Identification <Id> ++++ [0..1] Party6 hoice 9.1.13 {Or OrganisationIdentification <OrgId> +++++ [1..1] Organisation Identification4 Information that locates and identifies a specific address, as defined by postal services, presented in free format text. Unique and unambiguous identification of a party. Unique and unambiguous way to identify an organisation. This message item is part of choice 9.1.12 Identification. 9.1.14 BIOrBEI <BIOrBEI> ++++++ [0..1] AnyBIIdentifier ode allocated to organisations by the ISO 9362 egistration Authority, under an international identification scheme, as described in the latest version of the standard ISO 9362 Banking (Banking telecommunication messages, Bank Identifier odes). Only a valid BI or BEI is allowed. Valid BEI and BI are registered with the ISO 9362 egistration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK ODE, OUNTY ODE, LOATION ODE, BANH ODE. The code, country code and location code are mandatory, while the branch code is optional. 9.1.15 Other <Othr> ++++++ [0..n] 9.1.16 Identification <Id> +++++++ [1..1] Text 9.1.33 ountryofesidence <tryofes> ++++ [0..1] ountryode ountry in which a person resides (the place of a person's home). In the case of a company, it is the country from which the affairs of that company are directed. The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code). 2.80 reditoraccount <dtracct> +++ [0..1] ashaccount16 1.1.0 Identification <Id> ++++ [1..1] AccountIdentificatio n4 hoice Unambiguous identification of the account of the creditor to which a credit entry will be posted as a result of the payment transaction. equired in all payments except local international cheque and local payment orders. Unique and unambiguous identification for the account between the account owner and the account servicer. 1.1.1 {Or IBAN <IBAN> +++++ [1..1] IBAN2007Identifier Format: [A- Z]{2,2}[0-9]{2,2}[azA-Z0-9]{1,30} 1.1.2 Or} Other <Othr> +++++ [1..1] GenericAccount Identification1 1.1.3 Identification <Id> ++++++ [1..1] ax34text maxlength: 34 1.1.4 SchemeName <SchmeNm> ++++++ [0..1] AccountSchemeNa me1 hoice International Bank Account Number (IBAN) - identifier used internationally by financial institutions to uniquely identify the account of a customer. Further specifications of the format and content of the IBAN can be found in the standard ISO 13616 "Banking and related financial services - International Bank Account Number (IBAN)" version 1997-10-01, or later revisions. A valid IBAN consists of all three of the following components: ountry ode, check digits and BBAN. Unique identification of an account, as assigned by the account servicer, using an identification scheme. Identification assigned by an institution. Local accountnumber that will be credited for the transactions Name of the identification scheme 1.1.5 {{Or ode <d> +++++++ [1..1] ExternalAccount Identification1ode maxlength: 4 Name of the identification scheme, in a coded form as published in an external list. Valid code: BBAN BSK Bank IG ver 1 av pain 001.001.03 ustomer redit Transfer Initiation 201201 S27 av 45
5.3.1 Information Structure ISO Index Or essage Item Tag Name Structural ult. Type Use in IG 2.81 Ultimatereditor <Ultmtdtr> +++ [0..1] PartyIdentification32 Defenitions / Spesial comments Ultimate party to which an amount of money is due. 9.1.0 Name <Nm> ++++ [0..1] ax140text maxlength: 140 9.1.1 PostalAddress <PstlAdr> ++++ [0..1] PostalAddress6 Name by which a party is known and which is usually used to identify that party. Information that locates and identifies a specific address, as defined by postal services. 9.1.5 StreetName <StrtNm> +++++ [0..1] ax70text maxlength: 70 9.1.7 Postode <Pstd> +++++ [0..1] ax16text maxlength: 16 9.1.8 TownName <TwnNm> +++++ [0..1] ax35text Name of a street or thoroughfare. Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting of mail. Name of a built-up area, with defined boundaries, and a local government. 9.1.10 ountry <try> +++++ [0..1] ountryode Nation with its own government. The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code). 9.1.11 AddressLine <AdrLine> +++++ [0..7] ax70text maxlength: 70 Information that locates and identifies a specific address, as defined by postal services, presented in free format text. 2.82 InstructionForreditorAgent <InstrFordtrAgt> +++ [0..n] InstructionFor reditoragent1 BD Further information related to the processing of the payment instruction, provided by the initiating party, and intended for the creditor agent. 2.83 ode <d> ++++ [0..1] Instruction ode BD oded information related to the processing of the payment instruction, provided by the initiating party, and intended for the creditor's agent. Excamples: HQB - (Ultimate) creditor must be paid by cheque. HOLD - Amount of money must be held for the (ultimate) creditor, who will call. Pay on identification. PHOB - Please advise/contact (ultimate) creditor/claimant by phone TELB - Please advise/contact (ultimate) creditor/claimant by the most efficient means of telecommunication 2.84 InstructionInformation <InstrInf> ++++ [0..1] ax140text maxlength: 140 BD Further information complementing the coded instruction or instruction to the creditor's agent that is bilaterally agreed or specific to a user community. 2.89 egulatoryeporting <gltryptg> +++ [0..10] egulatory eporting3 Information needed due to regulatory and statutory requirements. 11.1.4 Details <Dtls> ++++ [0..n] Structured egulatory eporting3 Set of s used to provide details on the regulatory reporting information. 11.1.8 ode <d> +++++ [0..1] ax10text maxlength: 10 11.1.10 Information <Inf> +++++ [0..n] ax35text 2.98 emittanceinformation <mtinf> +++ [0..1] emittance Information5 Specifies the nature, purpose, and reason for the transaction to be reported for regulatory and statutory requirements in a coded form. ontact the financial institution for information as to use of the, and updated code-list. Additional details that cater for specific domestic regulatory requirements. Information supplied to enable the matching of an entry with the items that the transfer is intended to settle, such as commercial invoices in an accounts' receivable system. Structured emittance information is preferred 2.99 Unstructured <Ustrd> ++++ [0..n] ax140text maxlength: 140 Information supplied to enable the matching/reconciliation of an entry with the items that the payment is intended to settle, such as commercial invoices in an accounts' receivable system, in an unstructured form. Domestic, max 1750 International, max 140 Structured remittance information is preferred BSK Bank IG ver 1 av pain 001.001.03 ustomer redit Transfer Initiation 201201 S28 av 45