Avgående betalningar Tjänstebeskrivning Pain

Transkript

1 1 Avgående betalningar Tjänstebeskrivning Pain

2 2 Innehåll 1 C2B-betalning Avgående betalningar-tjänsten Begrepp Betalningsmeddelanden Betalningsmeddelande från kunden till banken Responsmeddelande från banken till kunden Struktur för betalningsmeddelande Tecken och formateringar Sändning och mottagning av meddelanden Steg i processen Kanalkontroll Kontroll av mottagningar Utbetalning Avgående betalningar applikationskoder för material Behandlingstidtabeller Skapande av respons Annullering av skickat betalningsmaterial Pain.001-betalningsmeddelanden: struktur och innehåll per betalningstyp SEPA-betalning Tilläggstjänster för SEPA-girering (Additional Optional Services) Periodiska SEPA-betalningar Inhemskt ilgiro Utlandsbetalning Utlandsilgiro SWIFT-check Avgående betalningsuppdrag (Request for Transfer) Pain.002-responsmeddelanden Kanalrespons Mottagningsrespons Utbetalningsrespons Responsmeddelandets struktur Orsaker till förkastande Exempelmeddelanden Exempel på pain.001-betalningsmeddelanden SEPA-betalning... 53

3 SEPA-lönebetalning Inhemskt ilgiro Utlandsbetalning Utlandsilgiro SWIFT-check Avgående betalningsuppdrag, Request for Transfer Exempel på pain.001-responsmeddelanden Kanalrespons Mottagningsrespons Utbetalningsrespons Rådgivning och utredningar... 72

4 4 Version Publicerad Viktigaste förändringar Förändrad del POP bankernas BIC-kod korrigerad Förtydligande beskrivning Tecken och formateringar 2.1 Steg i process 3.5 Avgående betalningsuppdrag 1 C2B-betalning 1.1 Avgående betalningar-tjänsten Aktias tjänst Avgående betalningar gör det möjligt att betala med en materialtyp som baseras på den internationella meddelandestandarden. För att kunna använda tjänsten måste betalaren teckna ett serviceavtal om avgående betalningar med Aktia. I avtalet definieras bland annat servicekod, tillåtna debiteringskonton och avsändare av material. Tjänsten omfattar sändning av SEPA-betalningar, utlandsbetalningar och inhemska ilgiron. Det är endast tillåtet att skicka avgående betalningsuppdrag (Request for Transfer, MT101) om detta särskilt definierats som tillåtet i avtalet. Utöver avtalet om avgående betalningar bör den som skickar materialet ha ett avtal om sändningskanal för att kunna använda tjänsten. Avgående betalningsmaterial tas emot via Web Services-kanalen och materialöverföringen i Nätbanken för företag. De svarsmeddelanden som banken skapar anges så att de kan hämtas på den kanal via vilken betalningsmaterialet har sänts Begrepp Term C2B Servicekod Förfallodag Betalningsuppdrag Betalningsmeddelande, meddelande Betalningssats Täckningsrotation Sändningskanal, kanal Beskrivning Customer-to-bank. Allmän benämning för tjänst där kunden skickar material till banken för behandling. Typiskt avser termen pain.001-betalningsmaterial. Betalarkod som definierats i avtalet om avgående betalningar och som identifierar betalaren och serviceavtalet inom vars ramar materialet sänds. Obligatorisk uppgift för betalningsmaterialet. Anges i elementet Dbtr/Id/OrgId/BkPtyId. Det startdatum för genomförandet av betalningsuppdraget som betalaren meddelat banken. Den dag då betalaren vill att kontot ska debiteras. Om förfallodagen inte är en bankdag påbörjas genomförandet av uppdraget den bankdag som följer efter förfallodagen. Observera betalningstypsspecifika begränsningar angående förfallodagen! Varje Credit Transfer Transaction Information-del i meddelandet utgör ett betalningsuppdrag. En helhet som utgörs av delarna Group Header-, Payment Information- och Credit Transfer Transaction Information. En PaymentInformation-del. Tidsperiod varefter debitering av en betalningssats eller enskild transaktion utförs på nytt om debiteringen har misslyckats på grund av bristande täckning på kontot. Sätt varmed betalningsmaterialet sänds till banken och de

5 5 XML XML-schema Periodisk betalning responsmeddelanden som banken skapar tas emot. Möjliga sändningskanaler för materialet Avgående betalningar är materialöverföring i Aktias Nätbank för företag och Web Services-förbindelsen. Den som skickar materialet måste ha ett giltigt kanalavtal. Extensible Markup Language. Märkspråk med vilket betalningsmaterialen skapas. Beskriver den tillåtna strukturen för materialet. Betalningsmeddelandenas strukturella korrekthet granskas i banken mot ett schema som motsvarar meddelandetypen. Etablerad term som avser löner, pensioner och andra betalningar som typiskt betalas vid en viss tidpunkt flera gånger till samma mottagare. Periodiska SEPA-betalningar identifieras på satsnivå med SALA-värdet i koden Category Purpose. Den förfallodag som anges för materialet är den dag betalarens konto debiteras. Medlen krediteras på mottagarens konto i ett finländskt penninginstitut på följande dag oavsett vilket penninginstitutet är. Betalningsparter Debtor Betalare, kontoägare Den part från vars konto betalningen debiteras Ultimate Debtor Ursprunglig betalare, fakturamottagare, den som faktureras Den part som har köpt en vara eller tjänst och till vilken säljaren har levererat fakturan. Uppgiften Ultimate Debtor används om fakturamottagaren är en annan part än betalaren. Debtor Agent Betalarens bank Betalarens kontobank, det vill säga den bank som håller debiteringskontot. Initiating Party En part som skapar ett betalningsmaterial. Kan vara betalaren själv, en agentur eller företagets eget servicecenter. Creditor Betalningsmottagare Den part på vars konto betalningen betalas eller en check levereras. Ultimate Creditor Slutlig mottagare Den part som är den slutliga mottagaren av betalningen. Till exempel betalas en faktura på ett finansieringsbolags konto, medan betalningens slutliga mottagare är finansieringsbolagets kund. Creditor Agent Betalningsmottagarens bank Betalningsmottagarens kontobank, det vill säga den bank som håller krediteringskontot.

6 Betalningsmeddelanden Betalningsmeddelandena följer den internationella ISO standarden för betalningsmeddelanden. Meddelandebeskrivningarna och deras XML-schemadefinitioner finns på webbplatsen På samma webbplats finns även en extern kodlista för betalningar (Payments External Code List), som omfattar de standardenliga värdena för betalningsmeddelandenas kodfält. Meddelanden som sänds måste följa standarden. Finansbranschens Centralförbund (FC) har publicerat guiden ISO20022 betalningar, som är gemensam för banker verksamma i Finland och som beskriver de meddelandeelement som ska användas vid SEPA-betalningar, och det datainnehåll som ska ges i dessa. Utöver standarderna och den gemensamma guiden ska Aktias anvisningar för datainnehåll följas. Banken har rätt att förkasta meddelanden som har skickats med bristfälliga eller felaktiga uppgifter. Om meddelandet ger ett datainnehåll som inte ingår i anvisningarna för betalningstypen i fråga, lämnas överskottsuppgifter obehandlade. Tjänstebeskrivningarna kan ändras Betalningsmeddelande från kunden till banken Meddelandebeskrivningen för betalningsmeddelande som sänds till banken är CustomerCreditTransferInitiationV02 och XML-schemats kod är pain Med meddelandet avses en XML-schemaförekomst, det vill säga en helhet som utgörs av delarna Group Header, Payment Information och Credit Transfer Transaction Information Responsmeddelande från banken till kunden Meddelandebeskrivningen för det responsmeddelande som banken skapar är PaymentStatusReportV02 och XML-schemats kod är pain Responsmeddelanden skapas i olika skeden av processen och de anger resultatet av materialets behandling. Kunden måste alltid hämta och kontrollera responsen. Responsmeddelandet innehåller hänvisningar till det ursprungliga betalningsmaterialet och i vissa fall till enskilda transaktioner i detta. Respons på felaktiga satser och transaktioner skapas efter varje behandling. Responsen inkluderar information om de satser och transaktioner som har förkastats i behandlingen i fråga. Respons skapas endast en gång för respektive förkastad transaktion och satser. För transaktioner som ännu är under behandling och som har statuskoden PDNG, skapas en respons på utbetalningen efter varje behandling ifall transaktionerna inte kan genomföras Struktur för betalningsmeddelande Betalningsmeddelandet föregås av hela meddelandets rotelement <Document>. Rotelementet bör minst omfatta attributet xsi:schemalocation, som anger det använda schemat och dess version. Det egentliga betalningsmeddelandets struktur är indelat i tre nivåer: Group Header (del A) Delen Group Header förekommer endast en gång i betalningsmeddelandet och den omfattar identifikationsuppgifterna för betalningsmeddelandet. En Group Header kan omfatta en eller flera Payment Information-delar, d.v.s. betalningssatser, som var och en kan omfatta en eller flera betalningar Payment Information (del B) Det kan finnas en eller flera Payment Information-delar i ett meddelande. Payment Information omfattar dataelementen för debiteringen, såsom debiteringskonto, förfallodag och servicekod. Informationen är den samma för alla betalningar som ingår i en sats. På satsnivå ges även eventuella definierande uppgifter för

7 7 betalningstypen. Om man vill skicka flera betalningar i samma material och dessa inte har samma betalningsuppgifter, måste man skapa separata satser för betalningarna Credit Transfer Transaction Information (del C) Credit Transfer Transaction Information, d.v.s. transaktionsnivån, omfattar dataelementen för kreditering av en enskild betalning. En Payment Information-del kan omfatta en eller flera Credit Transfer Transaction Information-delar. Källa: Unifi ISO20022 Message Definition Report Det största tillåtna transaktionsantalet för en betalningssats är transaktioner. Ett material som omfattar en eller flera satser, som är större än det tillåtna antalet, förkastas vid kanalkontrollerna. Detaljerade uppgifter om materialets datainnehåll per betalningstyp beskrivs i avsnitt Tecken och formateringar Kodningen för materialet avgående betalningar måste vara UTF-8. Kodpunkten Byte Order Mark (BOM) får inte användas. Skandinaviska bokstäver och separat definierade, tillåtna specialtecken förmedlas till finländska banker via SEPA-betalningar. Till övriga banker och vid betalningar utomlands förmedlas åtminstone tecken i teckenuppsättningen Basic Latin. Om det i betalningsuppgifterna finns ett tecken som inte kan förmedlas

8 8 som sådant till mottagarbanken, har banken rätt att förkasta betalningen, eller ersätta tecknet med ett tillåtet tecken i uppsättningen Basic Latin (t.ex. frågetecken). För att undvika teckenkonversion av identifikationsuppgifterna och för att kunna bibehålla betalningens identifikation genom hela processen, bör man inte i identifikationsuppgifterna använda andra tecken än de som ingår i uppsättningen Basic Latin (a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z / -? : ( )., ' + Space). Om materialet omfattar så kallade kontrolltecken, t.ex. tabulering, förkastas det alltid vid kanalkontroll. Formatering av material ska alltid ske med mellanslag i stället för tabulering. Vissa specialtecken ersätts enligt XML-standarden. Följande specialtecken måste anges som entiteter. Tecken & Entitet & < < > > " " ' &apos; Inga andra tecken får anges som entiteter. 2 Sändning och mottagning av meddelanden 2.1 Steg i processen Kanalkontroll 1) Kunden skickar betalningsmaterialet. 2) Banken identifierar avsändaren, kontrollerar avsändarens behörighet att skicka materialtypen i fråga, kontrollerar materialets strukturella korrekthet och kontrollerar avtal och datum på övergripande nivå. Till följd av dessa kontroller godkänns materialet som helhet antingen för fortsatt behandling, eller så förkastas det. 3) Banken ger ett svarsmeddelande som anger om sändningen har lyckats eller misslyckats. 4) Banken skapar ett responsmeddelande som anger om materialet har godkänts för fortsatt behandling eller förkastats. Ifall materialet har förkastats anger responsen orsaken till detta. Ett responsmeddelande skapas inte om överföringen misslyckas eller om betalningsmaterialet inte kan behandlas överhuvudtaget. I dessa fall ges informationen om förkastandet endast i responsmeddelandet. 5) Kunden avhämtar responsmeddelandet Kontroll av mottagningar 1) Material som passerat kanalkontrollen förmedlas till fortsatt behandling, där banken kontrollerar om transaktionerna kan genomföras. Materialets korrekthet kontrolleras på sats- och transaktionsnivå. Satser och/eller material som inte passerar kontrollen förkastas. 2) Banken skapar ett responsmeddelande som beskriver resultatet av mottagningskontrollen. För varje material skapas ett responsmeddelande. Responsen skapas alltid. Materialet kan antingen a. Godkännas helt (Group Status ACCP) b. Förkastas helt (Group Status RJCT)

9 9 c. Godkännas delvis (Group Status PART) Med responsen meddelas identifikationsuppgifterna för satser och/eller transaktioner som förkastats, samt orsak till och beskrivning av förkastandet. 3) Kunden avhämtar responsmeddelandet. För förkastade transaktioner måste kunden skapa och skicka nya, korrigerade uppdrag Dubblettkontroll Vid mottagningskontrollen görs, vid sidan av övriga kontroller, även en dubblettkontroll för satserna, vilket förhindrar att behandlingsmaterial som skickats dubbelt behandlas. Kontrollen görs per sats, och baseras på nedanstående uppgifter. Satsen kan tolkas som dubbel, om betalningsmeddelandets kod (Msgld), satsens kod (PmtInfld), satsens servicekod och det sammanlagda beloppet av betalningarna i satsen alla är samma som i en sats som skickats inom 3 mån. tidigare. En sats som tolkas som dubblerad förkastas och detta meddelas genom en respons från mottagningen. Om en tidigare skickad betalningssats har förkastats, kommer en post som skickats med samma uppgifter inte att genomgå dubblettkontroll. För att förhindra oavsiktligt förkastande bör betalningsmeddelandets kod vara unik i minst 3 månader. Ifall man vill skicka ett material på nytt bör man ändra identifikationsuppgifterna. Med meddelandeversionen Pain.001 är Payment Information Identification (PmtInfId) inte obligatorisk. Kunden måste observera att om materialet inte inkluderar PmtInfId, kommer materialet alltid att passera dubblettkontrollen. Kunden ansvarar för att det material denne skickat är korrekt, och behandlingen av ett dubblerat material kan inte ångras ifall posten redan gått till utbetalning. Banken utför dubblettkontroll enligt de ovan nämnda kriterierna, och om kunden vill utnyttja denna kontroll, bör PmtInfId anges för materialet Utbetalning Satser samt i dem ingående godkända transaktioner, som helt eller delvis passerat mottagningskontrollen, förmedlas till utbetalningsbehandlingen. Satserna plockas för utbetalning enligt förfallodag. Satser vars förfallodag är den innevarande dagen utbetalas vid följande möjliga utbetalning efter att materialet har genomgått mottagningskontroll. Satser med förfallodagen i framtiden lämnas för att vänta på förfallodagen och behandlas vid den första utbetalningsbehandlingen på förfallodagen. Satser vars förfallodag inte är en bankdag utbetalas på följande bankdag. Förfallodagen för lönematerial (SEPA-satser som på satsnivå har getts SALA som Category Purpose) måste vara en bankdag eller så förkastas satsen vid mottagningskontrollen. Förfallodagen för inhemska ilgiron måste vara den innevarande dagen och ilgirosatser kan endast skickas på bankdagar. I utbetalningsskedet kontrolleras satserna och transaktionernas information på nytt. Dessutom kontrolleras täckningen på debiteringskontot. Kunden måste se till att täckningen på debiteringskontot motsvarar betalningsmaterialet på förfallodagen. Täckningen måste finnas på kontot innan utbetalningsbehandlingen påbörjas. Utförandet av betalningar som debiteras från kontot kan inte garanteras om täckningen på debiteringskontot ökas först vid samma utbetalningsbehandling. Bokningsordningen för betalningen är slumpmässig och om man försöker debitera innan en kreditering har bokförts på kontot blir debiteringen täckningslös. Täckningen för SEPA-betalningar kontrolleras per debiteringssats. Om täckningen på kontot inte räcker till för debiteringen av totalsumman för en sats, blir hela posten täckningslös. Täckningen för övriga transaktionstyper kontrolleras per transaktion. Om det i samma sats finns både betalningstransaktioner som

10 10 behandlas som SEPA-betalningar och utlandsbetalningar, bildas en debiteringssats för SEPA-betalningarna, och utlandsbetalningarna debiteras som enskilda transaktioner. I utbetalningsskedet prioriteras transaktionerna per betalningstyp och de debiteras i prioritetsordning. Prioriteten för en enskild betalning utgår från betalningstypen som definierats på satsnivå. Det vill säga om en SEPA-sats inkluderar en betalning som behandlas som utlandsbetalning, har den samma prioritet som SEPA-betalningarna. Debiteringsordningen är slumpmässig för betalningar med samma prioritet. Prioritet för betalningstyper: 1. Inhemska ilgiron (POPS-betalningar) 2. SEPA-betalningar (ink. periodiska betalningar) 3. Utlandsbetalningar och utlandsilgiron Debiteringsförsök för transaktioner som saknar täckning görs vid varje utbetalningsbehandling på förfallodagen. Om täckningen på kontot inte är tillräckligt ens vid den sista utbetalningen, förkastas transaktioner som saknar täckning. Undantaget är inhemska ilgiron för vilka endast ett debiteringsförsök görs. Om täckningen inte räcker vid den första utbetalningen förkastas betalningar som saknar täckning med en gång. Respons för utbetalning skapas endast i fall debiteringen av alla transaktioner inte lyckas. I responsen beaktas endast de transaktioner som har behandlats i utbetalningen i fråga, satser vars förfallodag ligger i framtiden och/eller satser/transaktioner som eventuellt redan har förkastats tidigare, rapporteras inte. Med responsen för utbetalningen rapporteras satser och transaktioner som har förkastats samt satser och transaktioner som har Pending-status, det vill säga som har lämnats i täckningsrotation eller manuell behandling. För satser och transaktioner som har Pending-status skapas en respons efter varje debiteringsförsök Avgående betalningar applikationskoder för material Materialtyp Avgående betalningar Betalningsmaterial Avgående betalningar Responsmaterial Avgående betalningar Ilgiromaterial Applikationskod XL XP XF Vi rekommenderar att ilgiron skickas som ett separat material med sin egen applikationskod. Ilgiron kan emellertid även skickas som en del av annat betalningsmaterial, dock alltid som en separat Payment Information-del. Mer anvisningar finns i avsnitt Sändning av material i tjänsten Web Services beskrivs i en separat beskrivning som finns på adressen Behandlingstidtabeller Material kan skickas till banken under alla veckodagar, dygnet runt. Kanalkontroller utförs och kanalrespons skapas omedelbart när materialet mottagits. Mottagningskontroll görs och respons på mottagningen skapas under behandlingstiderna inom cirka en halv timme efter att banken har mottagit materialet. Utbetalningsbehandlingen utförs på bankdagar enligt en separat publicerad tidtabell. Behandlingstiderna är

11 11 riktgivande och banken har rätt att ändra tidtabellerna. Vid behandlingen av avgående betalningar följs avbrottstiderna för respektive betalningstyp Skapande av respons 1) Kanalrespons: Skapas omedelbart vid mottagning och kan avhämtas senast inom några minuter efter att materialet har skickats. Responsen skapas alltid om materialet har kunnat läsas. Respons skapas inte om sändningen misslyckas eller om materialet är felaktigt eller ifall det inte kan behandlas överhuvudtaget. I dessa fall ges informationen om misslyckad sändning med WS-kanalens svarsmeddelande och vid materialöverföring till Nätbanken, för företag visas felmeddelandet för kunden via användargränssnittet. 2) Mottagningsrespons: Skapas genast efter att mottagningen kontrollerats och kan avhämtas inom cirka en halv timme. 3) Utbetalningsrespons: Skapas omedelbart efter att den dagliga utbetalningsbehandlingen har avslutats för de transaktioner vars debiteringar inte har kunnat genomföras på den aktuella förfallodagen Annullering av skickat betalningsmaterial Kunden kan be banken att annullera alla betalningssatser vars förfallodag ligger i framtiden. Begäran måste riktas till Aktias företagskundservice senast två timmar innan företagskundservicen stängs på den bankdag som föregår betalningsdagen. Om annulleringsbegäran görs senare, eller om den gäller en sats för innevarande dag, kan banken inte garantera att annulleringen behandlas. I begäran om annullering bör man identifiera varje betalningssats som man vill ångra. Detaljerade uppgifter om hur begäran om annullering ska göras fås via Aktias företagskundservice. För närvarande är det inte möjligt att ångra betalningsmaterial genom ett annulleringsmeddelande av materialtyp. 3 Pain.001-betalningsmeddelanden: struktur och innehåll per betalningstyp Läsanvisning för tabellerna: Index Element Obligatorisk Antal Exempelinneh åll Hänvisning till Innehåller ett elementnum exempel på mer enligt data som kan standarden inkluderas i ISO fältet. Elementnamn enligt schemat. /-tecknen före namnet anger hur långt in i XMLstrukturen elementet ligger. Element som är märkta med grått är övergripande element och de ges inte direkt något datainnehåll. Frivillig enligt schemat, men obligatorisk enligt bankens definition Obligatorisk, kan förekomma endast en gång. 1..n Obligatorisk, kan förekomma flera gånger Frivillig, Förklaring Tilläggsbeskrivn ing eller anvisning

12 12 kan förekomma endast en gång. 0..n Frivillig, kan förekomma flera gånger. Med Pain.001-betalningsmeddelanden är det möjligt att ange tilläggsuppgifter som underlättar allokering av betalningarna samt identifiering av betalningsparterna. Aktia förmedlar uppgifterna till mottagarens bank i enlighet med beskrivningen för respektive betalningstyp. Det beror på mottagarens bank om informationen förmedlas, därmed kan det inte garanteras att all information på betalningen förmedlas till mottagaren. 3.1 SEPA-betalning Som SEPA-betalningar kan man göra betalningar i eurobelopp inom SEPA-området. En betalningssats definieras som SEPA-betalningar med Service Level-värdet SEPA i delen Payment Information. Täckingskontroll för och debitering av SEPA-satser görs per sats. Om täckningen på betalarens konto inte räcker till för debitering av hela satsen, tolkas hela satsen som täckningslös. Om en SEPA-sats omfattar utlandsbetalningar som förmedlas i eurobelopp, behandlas dessa enligt behandlingsreglerna för utlandsbetalningar och debiteras som enskilda debiteringar separat från SEPAbetalningarna. Betalningar till SEPA-banker i eurobelopp förmedlas primärt som SEPA-betalningar ifall satsen inte har definierats som inhemskt ilgiro eller utlands ilorder. För SEPA-betalningar bör alltid användas avgiftskoden SLEV eller SHAR. Om betalningstypen inte har definierats på satsnivå och banken styr betalningen som en SEPA-betalning, iakttas inte någon annan avgiftskod för betalningen. Om satsen har definierats som SEPAbetalning på satsnivå (ServiceLevel SEPA), är endast avgiftskoden SLEV eller SHAR tillåten. SEPA-satser som skickas med andra avgiftskoder förkastas. Valutan för betalningar som ingår i en SEPA-sats bör vara EUR. Betalningar i annan valuta förkastas. SEPA-betalningar, för vilka betalningsmottagarens konto är i Aktia, bokförs på betalningsmottagarens konto genast när utbetalningsbehandlingen har slutförts. SEPA-betalningar som förmedlas till övriga banker förmedlas enligt de allmänna villkoren för betalningsförmedling och Aktias tidtabeller för behandling och avbrott Tilläggstjänster för SEPA-girering (Additional Optional Services) Bankerna i Finland har definierat följande tilläggstjänster för SEPA-girering. Information enligt tilläggstjänsterna förmedlas endast mellan sådana banker som är med i tjänsten i fråga Betalningsdag (AOS1 Acceptance Date) Finländska banker förmedlar information om betalningsdag via betalningstransaktionen, d.v.s. den dag betalarens konto debiteras. Uppgiften förmedlas även till betalningsmottagaren.

13 AOS2 Fakturaspecifikationer Tilläggstjänsten AOS2 gör det möjligt att förmedla uppgifterna för flera fakturor och kreditfakturor med en girering. Uppgifterna för fakturorna och kreditfakturorna ges genom att upprepa meddelandeuppgiften i strukturen (Strd-uppgiften). Det största tillåtna antalet för betalningsspecifikationer på en girering är 999 stycken. Den maximala längden för en enskild Strd-förekomst är 280 tecken. I antalet tecken inräknas även xml-taggar. Banken förkastar betalningar som har för långa specifikationsuppgifter. För en betalning som vid sidan av strukturell meddelandeuppgift även inkluderar betalningsspecifikationer bör man alltid även ange ett fritextmeddelande (Ustrd). Banken kontrollerar endast längden på samt antalet specifikationsuppgifter. Flera Strd-uppgifter förmedlas endast till de banker som tar emot sådana. Till övriga banker förmedlas den givna Ustrd-uppgiften. Mer information om AOS2-betalningsspecifikationer finns i beskrivningen Description of the SEPA Credit Transfer AOS2 for Finland som publicerats av Finansbranschens Centralförbund och som finns på webbplatsen Periodiska SEPA-betalningar Periodiska SEPA-betalningar (d.v.s. löner och pensioner) identifieras på satsnivå med SALA-värdet i koden Category Purpose. Endast uppgiften på satsnivå är betydelsefull och informationen på transaktionsnivå påverkar inte behandlingen. Övrigt avviker periodiska betalningar inte datainnehållsmässigt från övriga SEPA-betalningar. Category Purpose påverkar behandlingen av betalningen endast för SEPA-betalningar. Om betalningen behandlas som en inhemsk ilgiro, utlandsbetalning eller SWIFT-check, spelar SALA-koden ingen roll. Förfallodagen för periodiska SEPA-betalningar (Requested Execution date) är den dag då betalarens konto debiteras. Förfallodagen måste vara en bankdag, annars förkastas satsen. Krediteringar som betalas in på Aktias konton bokförs på kontona den bankdag som följer på debiteringsdagen. Betalningar som betalas till andra banker förmedlas till de andra bankerna följande bankdag. Täckningskontroll och debiteringsbokföring för periodiska SEPA-betalningar görs som för SEPA-betalningar. Periodiska SEPA-betalningar rapporteras emellertid inte genom betalningsförteckning och specificeras inte på kontoutdraget. Ämnet för en periodisk betalning kan anges i fältet Purpose i delen CreditTransfer. Endast koder enligt ISOstandarden är tillåtna. Finländska banker visar på betalningsmottagarens kontoutdrag förklaringarna för de koder som förtecknas nedan. SALA = lön PENS = pension STDY = studieförmån BECH = barnbidrag BENE = förmån SSBE = ersättning AGRT = jordbruksbetalning

14 14 TAXS = skatteåterbäring SEPA-betalning och periodisk SEPA-betalning Index Element Obligato Antal Exempelinnehåll Förklaring risk Document 1..1 Meddelandets rotelement Pain Betalningsmeddelande 1.0 GrpHdr 1..1 Group Header 1.1 /MsgId Identifikation av betalningsmeddelande. Måste vara unik minst i 3 månaders tid. Identifikationen används som ett kriterium vid dublettkontroll av betalningssatsen. 1.2 /CreDtTm T09:00:00+02:00 Betalningsmeddelandens tidsstämpel given av betalaren (datum och klockslag) 1.4 /BtchBookg 0..1 Inte i bruk 1.5 /NbOfTxs Belalarens givna, obligatoriska, antal av betalningstransaktioner, d.v.s. antal av CdtTrfTxInx-transaktioner i meddelandet. Banken kontrollerar uppgifterna, och ifall antalet inte stämmer överens med det verkliga antalet förkastas hela meddelandet. 1.6 /CtrlSum Den aritmetiska summan av CdtTrfTxInf-transaktionernas belopp (InstdAmt eller Eqvtamt). Valutorna har ingen inverkan. Banken kontrollerar inte den givna informationen. 1.7 /Grpg 1..1 MIXD Obligatoriskt element. Tillåtna värden är GRPD, SNGL eller MIXD. Det givna värdet inverkar inte på hanteringen av transaktionerna. 1.8 /InitgPty 1..1 Uppgifter om den som skapat meddelandet. Förmedlas inte till betalningsmottagaren eller kontoutdraget. 1.8 /InitgPty/Nm 1..1 Namnet på den som skapat meddelandet /InitgPty/PstlAdr/A drline[1-2] /InitgPty/PstlAdr/Ct ry 0 2 Adress på den som skapat meddelandet 1..1 Adressens landkod på den som skapat meddelandet. Obligatorisk ifall AdrLine är given. Landkoden bör vara ISO3166 kod, enligt Alpha PmtInf 1..n I varje meddelande bör det vara åtminstone en PmtInf-del, d.v.s. betalningssats. Innehållande

15 15 betalningarnas gemensamma uppgifter samt informationen gällande debiteringen ges på PmtInf-nivån. 2.1 /PmtInfId 0..1 Inte obligatorisk, men användning rekommenderas. Ifall informationen inte är given, kan inte dublettkontroll utföras. 2.2 /PmtMtd 1..1 TRF Obligatorisk. Värdet TRF bör användas på SEPAbetalningssatser. 2.3 /PmtTpInf/ //InstrPrty 0..1 NORM Inte obligatorisk. Värdet NORM kan användas vid SEPA betalningar. 2.5 //SvcLvl ///Cd 1..1 SEPA Inte obligatorisk. Vid SEPAbetalningar används värdet SEPA //CtgyPurp 0..1 SALA Används endast vid SEPAlönetransaktioner. SEPAbetalningssatser med SALA-koder debiteras från betalarens konto på förfallodagen och krediteras till mottagaren i finländska banker på följande bankdag /ReqdExctnDt Satsens obligatoriska förfallodag. Förfallodagen kan vara högst 120 dagar i framtiden. Datum som är högst 2 dagar i det förflutna hanteras som dagens datum. Ifall det givna förfallodagen inte är en bankdag, hanteras betalningarna på följande bankdag. OBS! SALA-kodade SEPA-lönebetalningssatsernas förfallodag bör vara en bankdag, annars förkastas satsen /Dbtr 1..1 Betalarens uppgifter 2.15 //Nm 0..1 Betalarens namn som betalaren angivit. Betalarens namn förmedlas enligt namn på bankens register //PstlAdr/AdrLine[1-2] 0..1 Betalarens adress. Varken förmedlas till betalningsmottagaren eller sparas på kontoutdraget //PstlAdr/Ctry 1..1 Adressens landskod. Oblikatorisk ifall AdrLine är given. Landkoden bör vara ISO3166 kod, enligt Alpha ///Id 0..1 Betalarens identifikation 2.19 ////OrgId 1..1 Företagets identifikation. Servicekoden (BkPtyId) är obligatorisk. Den förmedlas inte till betalningsmottagaren. Utöver servicekoden kan man ge en annan identifiering, som förmedlas på betalningar /////BkPrtyId x Obligatorisk. Servicekoden som definierats i avtalet om avgående betalningar.

16 /////PrtryId/Id /DbtrAcct/ 1..1 Debiteringskonto 2.16 //Id/IBAN 0..1 FI Kontonumret av debiteringskontot. Debiteringskonto bör ges i IBAN format /DbtrAgt/ 1..1 Uppgifter om betalarens bank 2.17 //FinInstnId/BIC 1..1 HELSFIHH Aktias BIC 2.19 /UltmtDbtr/ 0..1 Ursprungliga betalarens uppgifter. Möjligt att ges antingen på satsnivå eller på transaktionsnivå. Ifall informationen ges på satsnivå, används den vid alla betalningar i satsen. Ifall informationen ges både på satsnivå samt transaktionsnivå, används informationen från satsnivå. Förmedlas till mottagaren på SEPA betalningar //Nm 0..1 Ursprungliga betalarens namn //PstlAdr/AdrLine[1-2] 0..1 Ursprungliga betalarens adress. Förmedlas inte till betalningsmottagaren eller sparas till kontoutdraget. //PstlAdr/Ctry 0..1 FI Adressens landskod på ursprungliga betalaren. Obligatorisk ifall AdrLine är given. Landskoden bör vara ISO3166 kod, enligt Alpha ///Id 0..1 Ursprungliga betalarens identifikation 2.19 OR ////OrgId 1..1 Företagets identifikation. Enbart en identifikation är tillåten /////PrtryId/Id OR ////PrvtId 1..1 Privatpersonens identifikation. Enbart en identifikation är tillåten. OBS! Personuppgiftslagen kontrollerar använding av personbeteckning /////CstmrNb 0..1 Kundnummer 2.19 /////PrvtId/SclSctyN 0..1 Personbeteckning b 2.19 /////DtAndPlcOfBirt 0..1 Födelsedatum h/birthdt 2.19 /////Othr/Id [1] 0..1 Övrig identifikation av privatpersonen 2.19 /////Othr/Id/IdTp [1] 0..1 Typen av övrig identifikation

17 /ChrgBr 0..1 SLEV Kostnadskod. Uttrycker vem eller vilka parter ansvarar för avgifter gällande betalning av kostnader. Kostnadskoden kan ges antingen på satsnivån eller på transaktionsnivån. Ifall koden inte är given på transaktionsnivån, används information från satsnivån. Vid SEPA betalningar är den enda tillåtna kostnadskoden SLEV. Kostnadskodens värden SHAR och TOM ändras till värdet SLEV /CdtTrfTxInf 1..n Varje PmtInf-del bör innehålla minst en CdtTrfTxInf -del //PmtId 1..1 Betalningens identifikationsuppgifter 2.25 ///InstrId Betalningens identifikation, som förmedlas till betalarens respons och kontoutdrag. Informationen förmedlas inte till mottagaren ///EndToEndId 1..1 NOTPROVIDED Obligatorisk betalnings identifikation, som förmedlas till mottagaren. Till betalarens kontoutdrag förmedlas informationen enbart av enstaka betalade betalningar. Ifall man inte vill använda informationen, ges NOTPROVIDED som värde //Amt 1..1 Det betalda beloppets information 2.38 ///InstdAmt Beloppet. Skall vara mellan EUR Betalningens valuta. Enbart EUR tillåten ///EqvtAmt/ ///EqvtAmt/Amt 0..1 Alternativa sätt at ge betalningens belopp Ccy 1..1 Alternativa sätt att ge betalningens valuta. Enbart EUR tillåten //ChrgBr 0..1 SLEV Kostnadskod. Uttrycker vem eller vilka parter ansvarar för avgifter gällande betalning av kostnader. Kostnadskoden kan ges antingen på satsnivån eller på transaktionsnivån. Ifall koden inte är given på transaktionsnivån, används information från satsnivån. Vid SEPA betalningar är den enda tillåtna kostnadskoden SLEV. Kostnadskodens värden SHAR och TOM ändras till värdet SLEV //UltmtDbtr 0..1 Ursprungliga betalarens uppgifter. Möjligt att ges antingen på satsnivån eller på transaktionsnivån. Ifall informationen ges på satsnivån, används den vid alla betalningar i satsen. Ifall informationen ges både på satsnivån samt

18 18 transaktionsnivån, används informationen från satsnivån ///Nm 0..1 Ursprungliga betalarens namn ///PstlAdr/AdrLine[ 1-2] 0..1 Ursprungliga betalarens adress. Förmedlas inte till betalningsmottagaren eller sparas till kontoutdraget ///PstlAdr/Ctry 0..1 Adressens landskod på ursprungliga betalaren. Obligatorisk ifall AdrLine är given. Landskoden bör vara ISO3166 kod, enligt Alpha ///Id 0..1 Ursprungliga betalarens identifikation 2.48 OR ////OrgId 1..1 Företagets identifikation. Enbart en identifikation är tillåten /////PrtryId/Id 0..1 Övrig identifikation 2.48 OR ////PrvtId 1..1 Privatpersonens identifikation. Enbart en identifikation är tillåten. OBS! Personuppgiftslagen kontrollerar använding av personbeteckning /////CstmrNb 0..1 Kundnummer 2.48 /////PrvtId/SclSctyN 0..1 Personbeteckning b 2.48 /////DtAndPlcOfBirt 0..1 Födelsedatum h/birthdt 2.48 /////Othr/Id [1] 0..1 Övrig identifikation av privatpersonen 2.48 /////Othr/Id/IdTp [1] 0..1 Typen av övrig identifikation 2.55 //CdtrAgt 0..1 Mottagarbankens uppgifter 2.55 ///FinInstnId ////BIC 1..1 OKOYFIHH Mottagarbankens BIC-kod. Vid SEPA betalningar inte obligatorisk. Ifall mottagarens kontonummer är given i IBAN-format, hämtas mottagarbankens BIC-kod från bankens register på basen av IBAN kontonummer. Vid betalning angiven BIC-kod utnyttjas enbart ifall mottagarens kontonummer är given i annan än IBAN format, eller ifall BIC koden inte finns i bankens register på basen av IBAN OR ////CmbndId OR /////BIC 0..1 Alternativa sätt att ange mottagarbankens BIC-kod 2.57 //Cdtr/ 1..1 Mottagarens uppgifter 2.57 ///Nm 1..1 Maksun Saaja Oy Mottagarens namn 2.57 ///PstlAdr/AdrLine[ 1-2] 0..2 Osoitekatu Helsinki Mottagarens adress. Obligatorisk vid utlandsbetalningar ///PstlAdr/Ctry 0..1 FI Landskoden för mottagarens adress. Obligatorisk, ifall adressuppgifter angivna. Landskoden bör vara ISO3166 kod, enligt Alpha-2.

19 ///Id Mottagarens identifikation 2.57 ////OrgId Företagets identifikation. Enbart en identifikation är tillåten /////PrtryId/Id Övrig identifikation 2.57 ////PrvtId Privatpersonens identifikation. Enbart en identifikation är tillåten. Informationen förmedlas bara vid SEPA betalningar. OBS! Personuppgiftslagen kontrollerar användning av personbeteckning /////CstmrNb Kundnummer 2.57 /////PrvtId/SclSctyN Personbeteckning b 2.57 /////DtAndPlcOfBirt Födelsedatum h/birthdt 2.57 /////Othr/Id [1] 0..1 Övrig identifikation av privatpersonen 2.57 /////Othr/Id/IdTp [1] 0..1 Typen av övrig identifikation 2.58 //CdtrAcct 0..1 Mottagarens kontonummer. Obligatorisk information, förutom SWIFT-checken ///Id/IBAN x 0..1 FI Mottagarens kontonummer i IBANformat. IBAN är obligatorisk vid SEPA-betalningar //UltmtCdtr 0..1 Slutliga mottagarens uppgifter 2.59 ///Nm 0..1 Lopullinen Saaja Oy Slutliga mottagarens namn 2.59 ///PstlAdr/AdrLine[ 1-2] 0..1 Osoitekatu Helsinki Slutliga mottagarens adress. Förmedlas inte till betalningsmottagaren eller sparas till kontoutdraget ///PstlAdr/Ctry 0..1 FI Adressens landskod på slutliga mottagaren. Obligatorisk ifall AdrLine är given. Landskoden bör vara ISO3166 kod, enligt Alpha ///Id 0..1 Slutliga mottagarens identifikation 2.59 ////OrgId Företagets identifikation. Enbart en identifikation är tillåten. Informationen förmedlas bara vid SEPA betalningar /////PrtryId/Id 0..1 Övrig identifikation 2.59 ////PrvtId Privatpersonens identifikation. Enbart en identifikation är tillåten. OBS! Personuppgiftslagen kontrollerar använding av personbeteckning /////CstmrNb Kundnummer 2.59 /////PrvtId/SclSctyN Personbeteckning b 2.59 /////DtAndPlcOfBirt Födelsedatum h/birthdt 2.59 /////Othr/Id [1] 0..1 Övrig identifikation av privatpersonen 2.59 /////Othr/Id/IdTp [1] 0..1 Typen av övrig identifikation 2.64 //Purp //Purp/Cd 0..1 SALA Purpose-kod. Bör vara enligt ISO External Code List. Förmedlas

20 20 enbart på SEPA-betalningar //RmtInf ///Ustrd 0..1 Friformigt meddelande till betalningsmottagaren ///Strd 0..n Strukturerad meddelande till betalningsmottagare 2.87 ////RfrdDocInf /////RfrdDocTp 0..1 Typ av faktura 2.89 //////Cd 1..1 CINV CINV = faktura CREN = kreditfaktura Ifall oden inte är angiven, eller det givna värdet är annat än CINV eller CREN, sparar banken värdet CINV på transaktionen /////RfrdDocNb 0..1 Faktura/kreditfaktura nummer 2.93 ////RfrdDocRltdDt 0..1 Datumet på fakturan. Inte i bruk för tillfället ////RfrdDocAmt 0..n Fakturans eller kreditfakturans belopp och valuta 2.97 /////RmtdAmt Fakturans belopp. Oberoende av i vilket fält beloppet är angiven, banken sparar och förmedlar den som RemittedAmount, ifall typ av faktura är CINV, eller koden inte är angiven /////RmtdAmt/@Cc y 0..1 EUR Valutakoden för fakturans belopp. Vid specificering av flera fakturor, sparas och förmedlas valutakoden alltid som EUR, oberoende av om valutakoden angivits i materialet /////CdtNoteAmt Kreditfakturans belopp. Oberoende av i vilket fält beloppet är angiven, banken sparar och förmedlar den som CdtNtAmt, ifall typ av faktura är CREN /////CdtNoteAmt/@ Ccy 0..1 EUR Valutakoden för kreditfakturans belopp. Vid specificering av flera fakturor, sparas och förmedlas valutakoden alltid som EUR, oberoende av om valutakoden angivits i materialet ////CdtrRefInf /////CdtrRefTp //////Cd 1..1 SCOR Obligatorisk, ifall referensnumrets typinformation är given. Endast värdet SCOR tas i beaktan /////Issr 0..1 ISO Berättar enligt vilken standard referensnumret är bildat. Ifall i fältet CdtrRef finns RF-referens, ges i detta fält värdet ISO /////CdtrRef Referensnummer. Banken förmedlar i referensfältet enbart valida nationella referensnumror eller RFreferenser. Ifall den angivna referensen inte är valid, flyttas den till meddelandefältets (2.85) första rad. I AOS2-specifiering flyttas icke-

21 21 valida referenser till fältet ////AddtlRmtInf[1] 0..1 Fakturans/kreditfakturans friformiga meddelande. Ifall i AOS2- specifiering i fältet CdtrRef angivna referensnummer inte är en valid nationell referensnummer eller RFreferens, förs fältets information i detta fält. 3.2 Inhemskt ilgiro Inhemska ilgiron kan betalas till de finländska banker som är med i POPS-systemet: Aktia Sparbankerna POP Bankerna Danske Bank DnB NOR Handelsbanken Nordea OP Danske Bank SEB S-Banken Ålandsbanken HELSFIHH ITELFIHH POPFFI22 DABAFIHH DNBAFIHX HANDFIHH NDEAFIHH OKOYFIHH DABAFIHH ESSEFIHX SBANFIHH AABAFI22 Betalningstypen för ilgiron definieras på satsnivån, varvid alla betalningar i satsen behandlas som ilgiron. Ilgiron identifieras på satsnivån med värdet HIGH i elementet <InstrParty>. Värdet är betydelsefullt endast på satsnivån. Om värdet ges på transaktionsnivån beaktas det inte. Vi rekommenderar att ilgiromaterial skickas som separat material med applikationskoden XF. Materialet kan även skickas med applikationskoden XL. Vi rekommenderar att inhemska ilgiron skickas som ett separat material som inte inkluderar andra betalningstyper. Ett material som innehåller så mycket som en ilgirosats förkastas i sin helhet vid kanalkontroll om den sista mottagningstidpunkten (cut off) för inhemska ilgiron har passerats. Cut off-tiderna finns på adressen Ilgiron kan endast skickas på bankdagar. Ilgiromaterial som skickas på icke-bankdagar förkastas vid kanalkontrollen. Förfallodagen för en ilgirosats måste vara innevarande dag. En förfallodag som ligger i framtiden godkänns inte, utan satsen förkastas vid mottagningskontrollen. Ilgiron behandlas enligt den normala tidtabellen för utbetalningar och förmedlas därefter så fort som möjligt till betalningsmottagarens bank. Betalningar som skickats som ilgiron och för vilka betalningsmottagarens konto är i Aktia, behandlas som SEPA-betalningar och bokförs på betalningsmottagarens konto genast när utbetalningsbehandlingen har slutförts. Index Element Obligato Antal Exempelinnehåll Förklaring risk Document 1..1 Meddelandets rotelement Pain Betalningsmeddelande

22 GrpHdr 1..1 Group Header 1.1 /MsgId Identifikation av betalningsmeddelande. Måste vara unik minst i 3 månaders tid. Identifikationen används som ett kriterium vid dublettkontroll av betalningssatsen. 1.2 /CreDtTm T09:00:00+02:00 Betalningsmeddelandets tidsstämpel given av betalaren (datum och klockslag) 1.4 /BtchBookg 0..1 Inte i bruk 1.5 /NbOfTxs Belalarens givna, obligatoriska, antal av betalningstransaktioner, d.v.s. antal av CdtTrfTxInxtransaktioner i meddelandet. Banken kontrollerar uppgifterna, och ifall antalet inte stämmer överens med det verkliga antalet, förkastas hela meddelandet. 1.6 /CtrlSum Den aritmetiska summan av CdtTrfTxInf-transaktionernas belopp (InstdAmt eller Eqvtamt). Valutorna har ingen inverkan. Banken kontrollerar inte den givna informationen. 1.7 /Grpg 1..1 MIXD Obligatoriskt element. Tillåtna värden är GRPD, SNGL eller MIXD. Det givna värdet inverkar inte på hanteringen av transaktionerna. 1.8 /InitgPty 1..1 Uppgifter om den som skapat meddelandet. Förmedlas inte till betalningsmottagaren eller kontoutdraget. 1.8 //Nm 1..1 Namnet på den som skapat meddelandet 1.8 //PstlAdr/AdrLine[1-2] 0 2 Adress på den som skapat meddelandet 1.8 //PstlAdr/Ctry 1..1 Adressens landskod på den som skapat meddelandet. Obligatorisk ifall AdrLine är given. Landskoden bör vara ISO3166 kod, enligt Alpha PmtInf 1..n I varje meddelande bör det vara åtminstone en PmtInfdel, d.v.s. betalningssats. Innehållande betalningarnas gemensamma uppgifter samt informationen gällande debiteringen ges på PmtInfnivån. 2.1 /PmtInfId 0..1 Inte obligatorisk, men användning rekommenderas. Ifall informationen inte är given, kan inte dublettkontroll utföras.

23 /PmtMtd 1..1 TRF Obligatorisk. Värdet TRF bör användas. 2.3 /PmtTpInf //InstrPrty 0..1 HIGH Värdet HIGH bör ges vid inhemska ilgiron. Bör ges på satsnivån och gäller alla betalningar i satsen. Information given på transaktionsnivå beaktas inte. 2.5 //SvcLvl 0..1 Inte obligatorisk vid inhemska ilgiron. Det givna värdet påverkar inte behandlingen av betalningar //CtgyPurp 0..1 Inte i bruk. Inhemska ilgiron med Category Purpose SALA behandlas som vanliga ilgiron /ReqdExctnDt Satsens obligatoriska förfallodag. Inhemska ilgirons förfallodag bör vara dagens bankdatum, annars förkastas satsen /Dbtr 1..1 Betalarens uppgifter 2.15 //Nm 0..1 Betalarens namn som betalaren angivit. Betalarens namn förmedlas enligt namn på bankens register //PstlAdr/AdrLine[1-2] 0..1 Betalarens adress. Varken förmedlas till betalningsmottagaren eller sparas på kontoutdraget //PstlAdr/Ctry 1..1 FI Adressens landskod. Obligatorisk ifall AdrLine är given. Landskoden bör vara ISO3166 kod, enligt Alpha ///Id 0..1 Betalarens identifikation 2.19 ////OrgId 1..1 Företagets identifikation. Servicekoden (BkPtyId) är obligatorisk. Den förmedlas inte till betalningsmottagaren /////BkPtyId Obligatorisk. Servicekoden som definierats i avtalet om x avgående betalningar /DbtrAcct 1..1 Debiteringskonto 2.16 //Id/IBAN 0..1 FI Kontonumret av debiteringskonto. Debiteringskonto bör ges i IBAN format /DbtrAgt 1..1 Uppgifter om betalarens bank 2.17 //FinInstnId/BIC 1..1 HELSFIHH Aktias BIC 2.19 /UltmtDbtr 0..1 Ursprungliga betalarens uppgifter. Förmedlas inte till mottagaren //Nm 0..1 Ursprungliga betalarens namn.

24 //PstlAdr/AdrLine[1-2] 0..1 Ursprungliga betalarens adress. Förmedlas inte till betalningsmottagaren eller sparas till kontoutdraget. //PstlAdr/Ctry 0..1 FI Adressens landskod på ursprungliga betalaren. Obligatorisk ifall AdrLine är given. Landskoden bör vara ISO3166 kod, enligt Alpha-2. Förmedlas inte till betalningsmottagaren eller sparas till kontoutdraget ///Id 0..1 Inte i bruk 2.20 /ChrgBr 0..1 SHAR Inhemska ilgiron förmedlas alltid enligt kostnadskoden SHAR. Andra kostnadskoder beaktas inte /CdtTrfTxInf 1..n Varje PmtInf-del bör innehålla minst en CdtTrfTxInf -del //PmtId 1..1 Betalningens identifikationsuppgifter 2.25 ///InstrId 0..1 Betalningens identifikation, som förmedlas till betalarens respons och kontoutdrag. Informationen förmedlas inte till mottagaren ///EndToEndId 1..1 Obligatorisk betalnings identifikation. Genom inhemska ilgiron förmedlas inte informationen. Ifall man inte vill använda informationen, ges NOTPROVIDED som värde //Amt 1..1 Det betalda beloppets information 2.38 ///InstdAmt Beloppet ///InstdAmt/@Ccy 1..1 EUR Betalningens valuta. Enbart EUR tillåten ///EqvtAmt ///EqvtAmt/Amt 0..1 Alternativa sätt att ge betalningens belopp ///EqvtAmt/Amt/@Ccy 1..1 Alternativa sätt att ge betalningens valuta. Enbart EUR tillåten //ChrgBr 0..1 SHAR Inhemska ilgiron förmedlas alltid enligt kostnadskoden SHAR. Andra kostnadskoder beaktas inte //UltmtDbtr 0..1 Ursprungliga betalarens uppgifter. Förmedlas inte till mottagaren //CdtrAgt 0..1 Mottagarbankens uppgifter 2.55 ///FinInstnId 1..1

25 OR ////BIC 1..1 OKOYFIHH Mottagarbankens BIC-kod. Mottagarbankens BIC-kod hämtas från bankens register på basen av IBAN kontonummer. Vid betalning angiven BIC-kod utnyttjas enbart ifall BIC koden inte finns i bankens register på basen av IBAN OR ////CmbndId /////BIC 0..1 OKOYFIHH Alternativa sätt att ange mottagarbankens BIC-kod. Mottagarbankens BIC-kod hämtas från bankens register på basen av IBAN kontonummer. Vid betalning angiven BIC-kod utnyttjas enbart ifall BIC koden inte finns i bankens register på basen av IBAN //Cdtr/ 1..1 Mottagarens uppgifter 2.57 ///Nm 1..1 Mottagarens namn 2.57 ///PstlAdr/AdrLine[1-2] 0..2 Mottagarens adress. Förmedlas inte till mottagare ///PstlAdr/Ctry 0..1 FI Landskoden för mottagarens adress. Obligatorisk, ifall adressuppgifter angivna. Landkoden bör vara ISO3166 kod, enligt Alpha-2. Förmedlas inte till mottagaren ///Id Inte i bruk 2.58 //CdtrAcct 1..1 Mottagarens kontonummer. Obligatorisk information ///Id/IBAN 0..1 FI Mottagarens kontonummer i IBAN-format. IBAN är obligatorisk vid inhemska ilgiron //UltmtCdtr 0..1 Slutliga mottagarens uppgifter. Förmedlas inte till mottagare ///Id 0..1 Inte i bruk 2.84 //RmtInf x 0..1 Varken meddelande eller referens är obligatoriska på inhemska ilgiron ///Ustrd 0..1 Friformigt meddelande till betalningsmottagare ///Strd 0..n Strukturerad meddelande till betalningsmottagare. ////CdtrRefInf 0..1 /////CdtrRefTp 0..1 //////Cd 1..1 SCOR Obligatorisk, ifall referensnumrets typinformation är given. Endast värde SCOR tas i beaktan. /////Issr 0..1 Berättar enligt vilken standard referensnumret är bildat. Ifall i fältet CdtrRef finns RF-

26 26 referens, ges i detta fält värdet ISO. /////CdtrRef Referensnummer. Banken förmedlar i referensfältet enbart valida nationella referensnumror. Ifall den angivna referensen inte är valid, flyttas den till meddelandefältets (2.85) första rad. I inhemska ilgiron kan inte referensnumrets förmedling som referens inte garanteras. 3.3 Utlandsbetalning Alla betalningar som har en annan valuta än EUR förmedlas som utlandsbetalningar. Betalningar i eurobelopp som förmedlas till andra än SEPA-banker förmedlas också som utlandsbetalningar, liksom betalningar vars krediteringskonto är ett konto i Aktia och med en annan kontovaluta än EUR. Valutan för debiteringskontot påverkar inte definitionen av betalningstypen. De valutor som är tillåtna för betalningar finns förtecknade på Aktias webbplats på adressen Utlandsilgiro Utlandsilgiron kännetecknas av Service Level-värdet URGP som anges på satsnivån. Endast data angivet på satsnivån beaktas. Om uppgiften endast har angetts på transaktionsnivån beaktas den inte, och betalningen behandlas som en vanlig betalningsorder enligt beskrivningen i avsnitt 3.3. Om betalningen utifrån en uppgift på satsnivån tolkas som ett utlandsilgiro, förmedlas betalningar i eurobelopp till SEPAbanker som utlandsilgiron. Ilgiron förmedlas, från Aktia till mottagarbanken eller mottagarbankens korrespondentbank, en bankdag snabbare än motsvarande utlandsbetalning. Betalning som utlandsilgiro förpliktar inte betalningsmottagarens bank att behandla betalningen snabbare än normalt. Utlandsbetalning och utlandsilgiro Index Element Obligato Antal Exempelinnehåll Förklaring risk Document 1..1 Meddelandets rotelement Pain Betalningsmeddelande 1.0 GrpHdr 1..1 Group Header 1.1 /MsgId Identifikation av betalningsmeddelande. Måste vara unik minst i 3 månaders tid. Identifikationen används som ett kriterium vid dublettkontroll av betalningssatsen. 1.2 /CreDtTm T09:00:00+02:00 Betalningsmeddelandens tidsstämpel given av betalaren (datum och klockslag) 1.4 /BtchBookg 0..1 Inte i bruk