Upload
trinhtram
View
214
Download
0
Embed Size (px)
Citation preview
Version Date Description of changes
April 2018 11.04.2018 • Name change from “Swiss Recommendations” to “Swiss Payment Standards”• Chapter 5: New template series of the ISO test platform• Chapter 6.1: Payment type 7 removed from the table• Chapter 6.4.2: Description adjusted to “Instruction Priority” (express order)• Chapter 6.8.2: Additional codes INTC/CORT for “Category Purpose”• Chapter 8: Limitation for the forwarding of information – usage adjusted
June 2017 30.06.2017 • First edition
Proof of review
2
1. Overview of ISO 20022 51.1. Use of ISO 20022 51.2. Features of ISO 20022 51.3. BenefitsforclientsofusingtheISO20022
standard 51.4. ISO 20022 messages 51.4.1. Payments Initiation 51.4.2. Cash Management 5
2. ISO 20022 Standards 62.1. Standards supported by UBS 62.1.1. Swiss Recommendations (SR) 62.1.2. German Banking Industry Committee (GBIC) 62.1.3. CGI (Common Global Implementation) 62.1.4. EPC (European Payments Council) 6
3. About this manual 73.1. The goal of this manual 73.2. Scope of application of this manual 73.2.1. Customer Credit Transfer Initiation (pain.001) 73.2.2. Customer Payment Status Report (pain.002) 73.3. Differentiation 7
4. Client interfaces for ISO 20022 messages 84.1. UBS KeyPort 84.1.1. UBS KeyPort Web 84.1.2. Contractual requirements 84.1.3. Technical Support 84.2. UBS e-Banking 84.2.1. Contractual requirements 84.2.2. Technical Support 84.3. UBS SWIFT for Corporate (FileAct) 94.3.1. Requirements 94.3.2. Support 9
5. ITP - ISO Test Platform 10
6. UBS Regulations on the use of pain.001 116.1. Types of payment 116.1.1. SEPA Payments 126.2. Grouping of Payment Types 13
6.3. Salary Payments 146.3.1. Account for General use 146.3.2. Salary Payments from a Dedicated Account 146.4. Execution date, order prioritization and
cut-offtimes 156.4.1. Execution Date 156.4.2. Instruction Priority 156.5. Currency, conversion 166.6. Notificationsinapaymentorder 166.6.1. Remittance Information 166.6.2. Purpose 176.7. Payment references 176.7.1. PaymentInformationIdentification 176.7.2. End–to-EndIdentification 176.8. Auftragsinstruktionen 186.8.1. Instructions to intermediary banks 186.8.2. Category purpose 196.9. Entry of additional actors 196.9.1. Ultimate Debtor and Ultimate Creditor 196.9.2. Intermediary Agent 206.10. Charges instructions 206.11. Charge account 216.12. Control of booking type and debit advices 216.12.1. Booking Type 216.12.2. Debit advice 216.12.3. Combinations of advices and booking types 226.13. Management of reports in ISO 20022 standard 23
7. Order status and rejects (pain.002) 247.1. Features of the status report 247.2. Overview of the possible status in reports 247.3. Warnings (ACWC) 257.4. Rejects (RJCT) 257.5. Order corrections 25
8. Limitation on forwarding information 26
9. Glossary 27
10. References 28
Contents
3
Appendix 29
11. Structure and most important elements of a pain.001 29
11.1. Structure of pain.001 message 2911.2. The most important elements of the A-Level –
“Group Header” 2911.2.1. Definition 2911.3. The most important elements of a B-Level –
“Payment Information” 3011.3.1. Definition 3011.4. The most important elements of a C-Level –
“Credit Transfer Transaction Information” 3111.4.1. Definition 31
4
1.1. Use of ISO 20022 ISO 20022 is an international standard for electronic data transmissioninthefinancialindustry.Itwasfirstusedtoimplement the SEPA initiative in European payment transactions. Since then, more and more countries are replacing their national procedures with the ISO 20022 standard, including Switzerland (e.g. replacement of the DME format by ISO 20022). The ISO 20022 standard is based on XML syntax (extensible Markup Language).
1.2. Features of ISO 20022ISO20022isthefinancialindustry’sagreedstandardfor:• producing uniform reporting standards for all business
processesinthefinancialindustry• developing structured and expandable reports• an opportunity to harmonize the large number of
standards• using the XML format
1.3. BenefitsforclientsofusingtheISO20022standard
Among other things, the standard means that all banks follow the same rules in validating messages. Another advantage is the end-to-end ID, which means that a paymentcanbetracedtothebeneficiary,oridentifiedunambiguously in the event of a rejection.The status report and harmonized error codes give the client greater and clearer transparency on the status of a submitted order. The XML format also provides the opportunity to transfer more comprehensive information, model complex types of ordersandrespondmoreflexiblyforfutureexpansions.
1.4. ISO 20022 messagesUBS supports the following ISO 20022 messages in the client-bank interface for “payments initiation” and “cash management”:
1.4.1. Payments Initiation• Customer Credit Transfer Initiation pain.001• Customer Direct Debit Initiation pain.008• Customer Payment Status Report pain.002
1.4.2. Cash Management• Customer Account Report camt.052• Customer Statement camt.053• CustomerDebit/CreditNotification camt.054
1. Overview of ISO 20022
5
Switzerlandhasdefinedacountry-specificstandardforpayment transactions (Six Interbank Clearing in cooperation withthefinancialinstitutions)basedonthestandardizedSEPA procedures, the Swiss Payment Standards (SPS).
There are also other international standards based on ISO 20022,suchasthestandardsissuedbytheGermanbanking industry and the Common Global Implementation (CGI) initiative.
2.1. Standards supported by UBS2.1.1. Swiss Payment Standards (SPS)The Swiss Payment Standards for implementing reporting standards for “Payments Initiation” and “Cash Management” based on ISO 20022 are being developed on behalf of the PaCoS (Payments Committee Switzerland), a committee of the Swiss Payments Council (SPC). The basis for this version is the “ISO Maintenance Release 2009” and the current EPC recommendations, as well as the "ISO Maintenance Release 2013” version for cash management.The Swiss Payment Standards consist of the following documents:• Swiss Business Rules• Swiss Implementation Guidelines for pain.001, pain.008,
pain.002 and for camt.052/053 and 054
UBS supports the “Major” versions of the Business Rules and Implementation Guidelines published by SIX Interbank Clearing AG, and the prior versions of these (always the two latest "major" guideline versions in parallel).
2.1.2. German Banking Industry Committee (GBIC)Appendix3“Specificationofdataformats”totheRDTAgreement is a collection of formats which are standardized and permissible for RDT with clients. They include formats for GBIC payment transactions (DTAUS, pain.00x subsets) and for SEPA. There is a separate manual for the use of ISO 20022 report types for UBS in accordance with the GBIC standard.
2.1.3. CGI (Common Global Implementation)The Common Global Implementation Initiative (CGI) seeks to standardize global payment transactions. The CGI Committee consists of SWIFT, several banks, corporate clients and system providers. The goal of CGI is to simplify implementation of ISO 20022 in payment transactions for users (companies and banks) to encourage broader acceptance of ISO 20022 as a uniform XML reporting standard between companies and banks. Reports to the CGI standard are processed by UBS in accordance with the scope and rules of the Swiss Recommendations.
2.1.4. EPC (European Payments Council)The EPC is responsible for implementation of SEPA (Single Euro Payments Area). EPC produces the rulebooks required for this.
SEPAwasoneofthefirstpaymenttransactionsinitiativesto use ISO 20022 to achieve its goals.
2. ISO 20022 Standards
6
3.1. The goal of this manualAs part of the Swiss payments transaction harmonization, Switzerlandasafinancialcenterisconvertingtheformatforfile-basedpaymentorderstotheISO20022standard.The standard is based on XML and is used for transfers, direct debits (DD, SEPA direct debit) and for reporting.
This manual describes the regulations applying to UBS Switzerland AG (UBS) in connection with the use of the ISO 20022 standard for transfers (Credit Transfer pain.001) and Status Report (pain.002), based on recommendations oftheSwissfinancialindustryforclient-bankdataexchange for the ISO 20022 standard (Swiss Payment Standards [SPS]). The detailed format description and its validation for this message type are shown at the UBS Implementation Guide “Credit transfer message pain.001” on the UBS homepage ubs.com/iso (Documents ISO 20022)
In addition, the UBS payment transaction conditions also apply in the ISO 20022 standard order.
3.2. Scope of application of this manual3.2.1. Customer Credit Transfer Initiation (pain.001)The message type pain.001 is used for electronic placement of payment orders. In Switzerland this type of message can be used for all kinds of transfers, i.e. voucher-based payments, domestic and foreign payments. In addition, a pain.001 can give instructions for order execution and downstream processes (e.g. report generation).
3.2.2. Customer Payment Status Report (pain.002)The Customer Payment Status Report is used to notify the client for a payment order based on ISO 20022 of thestatusofthesubmittedfile–positive(accepted) ornegative(rejected).Thepurposeisthenotificationof the status of the submitted message. The Status Report mustbeclearlydistinguishedfromaconfirmationofexecution,whichisconfirmedeitherbyadebitadvice or an account statement.
3.3. DifferentiationThe direct debit procedure (DD, SEPA Direct Debit) and the reporting (camt.) in the ISO 20022 standard and the associated messages in the ISO 20022 standard are documented in separate UBS manuals and Implementation Guides.In addition, the UBS payment transaction conditions also apply to order placements in the ISO 20022 standard.
3. About this manual
7
UBS provides three technical interfaces through which messages to the ISO 20022 standard can be submitted and received.• UBS KeyPort• UBS e-banking• UBS SWIFT for Corporates (FileAct)
4.1. UBS KeyPortUBSKeyPortisamodern,standardized,secureandflexiblecommunication link via the internet, based on EBICS (Electronic Banking Internet Communication Standard).
UBS KeyPort supports multibank electronic management of accounts via an EBICS client and is suitable for mid-sized and large corporations.
UBS KeyPort meets the latest security standards through the use of encryption and electronic signatures. UBS KeyPort supports a distributed electronic signature concept (VEU)andisbasedondifferentclassesofsignaturewhichcanbeusedtomodeldifferentiatedauthoritysystems.
4.1.1. UBS KeyPort WebUBS KeyPort Web also gives UBS an EBICS Client Portal. UBS KeyPort Web requires the installation of a signature plug-in which can be downloaded and installed from the UBS KeyPort website (provided the computer has the necessary installation rights).
Terminal infrastructures are not supported.
4.1.2. Contractual RequirementsAfterreceiptbyUBSSwitzerlandAGofthevalidlysignedUBS KeyPort contract each participant receives the personal data (bank parameter data sheet) to set up the key media and initialize bank access. The data will be sent by mail.
4.1.3. Technical SupportFurther information is available atubs.com/keyportweb-support
The UBS Cash Management Information & Services Hotline is also available.Tel.: 0848 807 848Hours: Monday–Friday, 08.00 – 18.00
4.2. UBS e-bankingWith UBS e-banking, banking transactions are simple and secure. For example, payments, account transfers and standing orders in Switzerland and abroad can be entered and managed.
The “data transfer” function is used to upload pain.001 paymentfiles,generatedwithpaymententrysoftwaretoUBS e-banking and to place payment orders.
4.2.1. Contractual RequirementsTo use UBS e-banking, a UBS account and a computer with internet access is required. In addition, a UBS e-banking agreement with a collective or individual signature is needed.
4.2.2. Technical Support The documentation “UBS e-banking – step by step explanation”offersfurtherinformationontheindividualfunctions of UBS e-banking (see ubs.com/support User guides).
UBS e-banking support is available around the clock for any questions you may have on UBS e-banking.Tel. 0848 848 064.
4. Client interfaces for ISO 20022 messages
8
4.3. UBS SWIFT for Corporate (FileAct) “UBSSWIFTforCorporates”offersprimarilyinternationallyactivefirmsandgroupssecure,reliableanddirectaccesstothefinancialindustry.UBSoffersallthreeaccessmodels(SCORE, MA-CUG and TRCO) and the services SWIFTNet FIN and SWIFTNet FileAct.
4.3.1. RequirementsTo communicate with UBS Switzerland AG via “SWIFT for Corporates,”atechnicallinkwithSWIFTisneeded.This means:• maintaining a separate SWIFT gateway or• communication via a service bureau or• connection through “SWIFT Alliance Lite,” moreover• a “SWIFT for Corporates” contract with UBS and• a contract with SWIFT
4.3.2. SupportWe should be glad to answer any questions:UBS Cash Management Information & Services HotlineTel.: 0848 807 848Hours: Monday – Friday, 08.00 – 18.00
9
An important aid in the course of the transfer is the UBS PaymentStandardstestplatform,whichsimulatesthebehavioroftheclient-bankinterfaceindetail,offeringanimportant aid to migration.
The test platform checks conformance of the generated client-to-bank messages (validation) and generates bank-to-client messages (simulation) in accordance with theSwissBusinessRulesandSwissandUBSImplementation Guidelines as well as the Standards of the GermanBankingIndustryCommittee.
5. ITP – ISO Test Platform
TheUBSPaymentStandardstestplatformmapstheofferingof the corresponding UBS channel. You can call up three differentchannels:UBSe-bankingFileTransfer,UBSe-banking OFX and UBS KeyPort.
With the UBS PaymentStandards test platform any of the softwarepartnersorbankclientsaffectedbythemigrationcan test for themselves.
Thanks to reliable and simple-to-perform checks of the ISO-20022-basedXMLfilesandthesimulationofthebank-
to-client messages with 24x7 “self-service”, a reduction in inputs can be achieved in development and end-to-end testing.
In addition, the actual migration process with UBS is greatly simplifiedandaccelerated,asALLrelevantscenariosoforder placement and reporting can be independently tested in advance using test data.
Useful links:• Registration for test platform
Sample page
10
Message type pain.001 for transfers makes it possible (instructions in the individual elements of pain.001) to manage execution and further processing of the payment order. In the enclosure we tell you about the most important functions and describe how they are handled at UBS Switzerland AG.
6.1. Types of paymentThe Swiss Payment Standards for ISO 20022 payments divide transfers into three areas:• transferstoafinancialinstitutioninSwitzerland• transferstoafinancialinstitutionabroad• domesticandforeigntransferswithoutafinancial
institution
All standard types of payment are supported in domestic and cross-border payment transactions, including SEPA payments.
6. UBS Regulations on the use of pain.001
UBS treatment The following type of payment is not supported by UBS if the order is placed through pain.001:• Payment type 8, Bank check/Postcash, Switzerland and abroad
Area in pain.001 Element Values UBS pain.001 validation rules
Payment Method<PmtMtd>
TRA TRF CHK
• “CHK” is the code to identify payment orders and checks. UBS does not support these payment methods. Transactions (C-Levels) with value “CHK” are rejected.
Local Instrument<LclInstrm> <Cd>
CPP • CPP is the code to identify the payment type “Payment order, domestic”. The Swiss Payment Standards SPS do not support this type of payment. Transactions (C-Levels) with value “CPP” are rejected.
Transfer area Payment type Title Description Currency
Domesticfinancialinstitution
1 ESR (payment slip with reference number)
Orange payment slip CHF and EUR
2.1 1-step payment slipRed payment slip (ES) CHF and EUR
2.2 2-step payment slip
3 IBAN/postal account and IID/BIC
Bank or postal payment CHF and EUR
4 Foreign currency Bank or postal payment inforeign currencies
All currencies except CHF and EUR
Financial institution abroad
5 Abroad (SEPA) SEPA Credit Transfer EUR
6 Outside Switzerland SWIFT All currencies
Withoutfinancialinstitution in Switzerland or abroad
7 Bank check/Postcash, Switzerland and abroad
Bank check/Postcash, Switzerland and abroad
All
11
6.1.1. SEPA PaymentsIf the criteria for a SEPA payment are met, UBS automatically makes the payment via SEPA (e.g. with payment type 4 or 6). The following criteria must be met for a payment to qualify for SEPA at UBS.• Transaction currency, euro• Recipient’sIBAN• Therecipient’sfinancialinstitutionisaparticipantin
SEPA• Distribution of charges between debtor and creditor
(service level and/or scheme, “SLEV”)
• No instructions to intermediary entities/banks in payment order
• DeliverywithinprevailingUBScut-offtimes• Amount of credit transfer is no greater than the
equivalent of CHF 24 million
However, a request for a SEPA payment can also be explicitly shown in a pain.001 (corresponds to payment type 5).
UBS treatment If a SEPA payment is explicitly requested in a pain.001, all SEPA criteria listed must be met.
Area in pain.001 Element Value UBS pain.001 validation rules
• Service Level Code <SvcLvl><Cd>
• Charge Bearer <ChrgBr>
SEPA
SLEV
• If a SEPA criterion is absent or not correct, the transactions involved (C-Levels) are rejected.
• Ifthepain.001occursafterthecut-offtimeforSEPApayments,the order will be carried out as a SEPA payment at the next pos-sible execution date (Status Report ACWC).
• If the amount of the transfer exceeds the limit for SEPA payments, it is executed as a foreign payment (Status Report ACWC).
12
UBS treatment Regrouping B-LevelsIn the following cases UBS undertakes regrouping:• over 9,999 transactions in one B-Level• orders with mixed currencies in one B-Level (only possible by separate agreement, AOS -
see explanation below)
Regrouping B-Levels in one pain.001 means that the B-Level (with BatchBooking “true”) is executed with various collective debits. Moreover, multiple pain.002s are also generated with thesamePaymentInformationIdentification.Thismeansthatautomatedstatuscomparison of the pain.002 is not possible.
AOS: processing orders with mixed currencies at B-LevelTransfersindifferentcurrenciescanonlybeconsolidatedinaB-Levelwithaseparateagreement with UBS. In this case, UBS undertakes regrouping. Debits are always in the same currency, i.e. one collective booking for each payment currency.
Area in pain.001 Elements Value UBS pain.001 validation rules
Currency<Amt><InstdAmt><Ccy>
Value in ISO format
• UBS rejects orders with different currencies per transaction (C-Level) within a B-Level.
6.2. Grouping of payment typesIn a pain.001 message, transactions (C-Level) can be consolidated (grouped) in a collective order (B-Level). Payments can be consolidated if they show certain common features, e.g. same Requested Execution Date, same Debtor Account or salary payments (Category Purpose SALA/PENS). Grouping salary payments in a single order (B-Level) is particularly recommended, with the transactions for normal execution in a separate order.
At UBS at most 9,999 transactions (C-Level) may be consolidated in one B-Level.
A message type pain.001 in the ISO format may only contain one currency for each collective order (B-Level).
13
6.3. Salary paymentsDetails of salary payments in account statements and debit advices are generally not desired for reasons of confidentiality.Theclienthasvariousoptionsforpreservingconfidentiality. SalarypaymentscanbeorderedatUBSintwodifferenttypes:1. with an account for general use 2. with a separate dedicated “salary” account
6.3.1. Account for General UseThe code “SALA” or “PENS” must be entered (element “Category Purpose”) in the payment order by pain.001 from this account (Element “Category Purpose”)
ThesalaryflagintheDMEstandardcorrespondstotheelement “Category Purpose” in ISO 20022 with the code “SALA” (salary) or “PENS” (pension).
UBS treatment • To suppress the details in a payment order (for salaries) the SALA or PENS code must be entered in the pain.001. Orders with the SALA or PENS codes are always processed by UBS without details.
• It is also recommended to group salary payments in one order (B-Level) and to deliver transactions for normal processing in a separate order.
• If the SALA or PENS code is present, UBS also always overrides the display type in accordance with section 7.13 (master data or instructions in pain.001).
Area in pain.001 Element Value UBS pain.001 validation rules
Category Purpose<CtgyPurp>
SALA/ PENS
• Salary codes always apply to an entire collective order (B-Level).
• As a result, the codes must always be entered at B-Level, as they are not recognized at the individual transaction level (C-Level).
6.3.2. Salary Payments from a Dedicated AccountThis option is generally used by clients which use dedicated payrollingsoftwareinconnectionwithadedicatedpayrollaccount which is used exclusively for salary payments. With message type pain.001 clients also have the option of
processing salary payments through dedicated accounts at UBS. In this case a payment order by pain.001 must not include the SALA or PENS salary code, so that details of creditors are shown on the messages and reports.
14
UBS treatment • For a desired execution date UBS observes the cut-offtimes. If the execution date is outside thecut-offtimeforthetransactioncurrency,thevaluedateispostponedtothenextpossible business day.
• Dependingonthecurrency-specificmarkethoursandordertype,UBSwillcarryoutprocessing of a payment order before the desired execution date.
• With the “Instruction Priority” function, UBS CHF Inland payment orders (type of payment 1, 2.1, 2.2 and 3) can be issued as express orders. These orders will still be excepted for processingonthesamedayuponreceiptafter12:30p.m.andwiththedesiredexecutiondate of “today”.
Area in pain.001 Element Value UBS pain.001 validation rules
RequestedExecution Date <ReqdExctnDt>
ISO-conform value
• The execution date may be at most 60 calendar days in thefutureoratmost10calendardaysinthepast (from submission)
Payment Type InformationInstruction Priority<InstrPrty>
HIGH/ NORM
• In order to process CHF payment orders as express orders, the “Instruction Priority” must be set to HIGH.
•IfthefieldissettoNORMorleftempty,theorderwillbeexecuted at 12:30 p.m. on the next business day.
• All other types of payment are executed according to the correspondingcut-offtimes.
6.4. Execution date, order prioritization and cut-offtimes
6.4.1. Execution DateThe element “Requested Execution Date” contains the desired execution date for the payment order (date on which the account is to be debited – value date).
6.4.2. Instruction PriorityTheelement“InstructionPriority”inISO20022definestheurgencyofprocessingatthedebtoragent'sfinancialinstitution.It isnotaninstructionforexecutionpriorityinthefinancialinstitution’spayments.
15
UBS treatment • You can place payment orders with UBS in all the currencies listed in the document “Cut-offtimes”.
• FurthercurrenciescanbespecifiedinorderswiththeserviceUBSPayWorldWide• UBS also supports the function EQUI (execution of a payment “in the equivalent of”).
This makes it possible to transfer an amount to a creditor in a currency which is equivalent to agivenamountinanothercurrency.
Area in pain.001 Element Value UBS pain.001 validation rules
• Instructed Amount <InstdAmt>
ISO-conform value
• The transfer amount can be either “Instructed Amount” or “Equivalent Amount”.
• IfdifferentcurrenciesareincludedinaB-Level,theorderisrejected (pain.002 reject), unless there is a corresponding agreement with UBS (AOS).
• Equivalent Amount <EqvtAmt>
ISO-conform value
• Currency <Ccy> ISO Code
6.5. Currency, conversion
6.6. NotificationsinapaymentorderThe debtor in a payment order via pain.001 has various optionsforforwardingnotificationsandinformationtothecreditor.
6.6.1. Remittance Information Thisfieldisusedtoforwardnotificationstothecreditorand consists of a number of sub elements which allow both unstructuredandstructurednotifications.Inbothcasesthenotificationmayhaveatmost140characters.Inthefield“CreditorReference”<CdtrRefInf>forstructurednotifications,theESRreference,IPIreference
or the international Creditor's Reference to ISO 11649 is shown.
Simultaneous use of both unstructured and unstructured remittance information is not allowed under the Swiss Payment Standards and results in rejection of the order (pain.002 reject).
In interbank payments and reports in legacy format, abbreviations may be used in remittance information because of the limits of the format (see also section 8).
UBS treatment In forwarding information to legacy formats (e.g. SWIFT) the structured information in remittance information is mapped into 4 x 35 characters of the unstructured remittance information.
Area in pain.001 Element Value UBS pain.001 validation rules
RemittanceInformation<RmtInf>• <RmtInf><Ustrd>• <RmtInf><Strd>
• Unstructured (max. 140 characters)
• Structured (e.g. ESR reference line)
• Simultaneous use of unstructured and structured remittance information results in rejection of the order (pain.002 reject).
16
6.7. Payment referencesFor the debtor (generator of pain.001) the following references from the message Customer Credit Transfer Initiation “pain.001”) are relevant:
6.7.1. PaymentInformationIdentificationThis reference is for the debtor, and is not forwarded to the creditor. The Payment Information ID is shown as a booking reference to identify the collective order (B-Level) in the account statement to support reconciliation.
6.7.2. End-to-EndIdentificationTheend-to-endIDisthedebtor’sreferenceofapain.001(nottheESRreference,whichisthebeneficiary’sreference).Theinformationisforwardedtothefinalbeneficiary,ifthisissupportedbythebeneficiary’sfinancialinstitution.
Itisamandatorynotificationinpain.001andmustbeshown for each individual (C-Level) transaction. The reference can be useful in the event of queries, so that apaymentbytheclientcanbeunambiguouslyidentified.
UBS treatment • TheB-LevelreferenceisreturnedasabookingreferenceincamtandinMT940(field61)for eachcollectiveorder.
• Theend-to-endIDisreturnedinMT940field86inaccordancewiththeSWIFTrules.
Area in pain.001 Elements Value UBS pain.001 validation rules
Payment Information Identification <PmtInfId>
Max. 35 characters at B-Level
• Must be unambiguous within a collective order(B-Level).
End-to-End Identification< EndToEndId>
Max. 35 characters at C-Level
• This is an obligatory field. If absent, the transaction(C-Level)isrejected.
6.6.2. PurposeThe purpose is to notify the type of payment. The purpose codehasnocontrolfunctionanddoesnotaffectprocessing of the payment order. The possible codes are managed in an external ISO 20022 list (External Purpose Code List)
Because of the limitation of the format, the purpose code cannot be forwarded with interbank payments and reports in legacy format (see also section 8).
UBS treatment All codes in accordance with the ISO 20022 external purpose code list may be used.
Area in pain.001 Element Value UBS pain.001 validation rules
Purpose Code<Purp><Cd>
• Valid ISO code • Only possible in coded form.
17
UBS treatment • For bank or postal payments in foreign currencies (payment type 4, see section 6.1) and credit transferstoafinancialinstitutionabroad(paymenttype6,seesection7.1),instructionstoUBS(e.g.forordersinCNYorRUB)and/orthebeneficiarybankcanbeattached.
• UBScannotinfluencecompliancewiththeinstructionsbythebeneficiarybank.• UBSdoesnotsupportordersforthebeneficiarytoissueabankcheck(SWIFTcheckswith
code value CHQB).
Area in pain.001 pain.001 elements
Value UBS pain.001 validation rules
Instruction For Debtor Agent<InstrForDbtrAgt>
Text, max. 140 characters • Transactions are rejected in the payment types 1, 2, 3 and 5.
• Code value CHQB is not supported (SWIFT checks). These transactions are rejected by UBS.
Instruction For Creditor Agent<InstrForCdtrAgt>
• Text, max. 140 characters• ISO Codes:
– PHOB– HOLD– TELB
6.8. Order instructions6.8.1. Instructions to intermediary banksFurther information on processing the payment via pain.001 (instructions) can be entered by the debtor.
Use of the elements “Instruction for Debtor Agent” and
“Creditor Agent” is only allowed for instructions not already shown in other elements of the standard. The predetermined elements must be used (e.g. Category Purpose Code for salary payments).
18
UBS treatment • Orders with SALA/PENS are always processed without details (salary payments). • Data regarding INTC or CORT will be forwarded to the creditor bank. When forwarding via
Swift, the codes are mapped in field 23E.
Area in pain.001 pain.001 elements Value UBS pain.001 validation rules
Category Purpose Code<CtgyPurp><Cd>
• SALA• PENS• INTC• CORTS
• UBS supports the instructions with code SALA/PENS, INTC or CORT.
• Other ISO-conform codes are not recognized. There is no forwardingtothecreditor’sbank.
• The codes SALA/PENS always apply to a collective order (B-Level). On the C-Level the codes SALA/PENS are not considered.
• Non-ISO-conform codes result in rejection of an order (B-Level) or transaction (C-Level).
UBS treatment As described above
Area in pain.001 Elements Wert UBS pain.001 validation rules
Ultimate Debtor<UltmtDbtr>
Name and address
• Can be used.
Ultimate Creditor<UltmtDbtr>
Name and address
• Can be used, except for payment types with vouchers (payment types 1, 2.1, 2.2)
6.9. Entry of additional actors6.9.1. Ultimate Debtor and Ultimate CreditorAn Ultimate Debtor can be entered in all pain.001 orders.An Ultimate Debtor can be entered for both the entire collective order (B-Level) and for individual transactions (C-Level). In the latter case the information applies only to the individual payment in question.
By contrast, the Ultimate Creditor must be given at individual transaction level (C-Level), if used.
For interbank payments and reports in legacy format, the limitonthenumberoffieldsorcharactersmaynotpermitinformation on Ultimate Debtor and Ultimate Creditor (see also section 8).
6.8.2. Category PurposeIn pain.001 the debtor for a payment order can provide instructions on processing the payment. This is done by an ISO code in the Category Purpose element. One example forthisistheSALAflagforsalarypayments.
The Category Purpose Code is for the commissioned bank andcanbeforwardedthroughallthefinancialinstitutionsinvolved in the payment change.
19
6.10. Charges instructionsInpain.001thefield“ChargeBearer”showswhich party or parties bear the charges for the payment order associated with processing the payment order.
The following instructions are possible: • SHA: charges shared (recommended)
• BEN: the creditor assumes all charges (UBS service charge is deducted from the transaction amount)
• OUR: charges assumed by debtor. OUR means that charges up to the creditor bank are covered, but not receipt pricing at the creditor bank.
UBS treatment The field is optional. If there is no entry, the default is SHA.Different charge options can be used for each transaction (C-Level) within a collective level (B-Level), unless already set at collective level (B-Level).
Area in pain.001 Elements Value UBS pain.001 validation rules
Charge Bearer<ChrgBr>
• DEBT (OUR)• CRED (BEN)• SHAR (SHA)• SLEV (for SEPA)
• If “SvcLevlCode” = SEPA, charge option SLEV must be used. SHAR is not allowed and results in rejection of the transaction.
UBS treatment A payment order with these instructions cannot be automatically processed (non-STP), which can leadtodelaysinexecutionandadditionalcosts;itisaccordinglyrecommendednottousethese instructions.
Use is only possible for bank or postal payment in foreign currencies (payment type 4) and transfers to a financial institution abroad (payment type 6).
Area in pain.001 Elements Value UBS pain.001 validation rules
Intermediary Agent<IntrmyAgt1>
BIC • MustincludethevalidBIC(BusinessIdentifierCode)of the correspondent bank, otherwise the transaction (C-Level) is rejected.
• Transactions are rejected for payment types 1, 2, 3 and 5.
6.9.2. Intermediary AgentThiselementcanbeusedtoshowthecreditorbank’scorrespondentbank.
20
6.12. Control of booking type and debit advices6.12.1. Booking typeThebookingtypeisalwaysdefinedbythepaymentorderpain.001. By default, i.e. without additional instructions, orders are individually booked by transaction (C-Level). Orders with multiple entries (C-Levels) are collectively booked.
Possiblevaluesinpain.001andtheirsignificance:• “true”: if possible, one collective booking is made for
each order• “false”: booking is for each transaction (C-Level)• “empty”: is always equivalent to the value “true”
6.13.2. Debit AdvicesThe choice of debit advice and format (paper, SWIFT, ISO standard) is determined by the client and saved at UBS in the master datas. These values control the individual advices and data content of the debit advices.
The following options are available:• Global advice (without details)• Detailed advice• No advice
With pain.001 the individual advice (debit advice) can be individually selected by order and transaction. This overridesthedefinitionsinthemasterdata.
Possiblevaluesinpain.001andtheirsignificance:• NOA: No Advice• SIA: Single Advice• CND: Collective Advice No Details• CWD: Collective Advice With Details
6.11. Charge accountThis is used to show a separate account for debiting charges.
UBS treatment UBS debits any charges (for OUR, SHA or SLEV) to the debtor account shown in the pain.001 for the payment order.
Area in pain.001 Elements Value UBS pain.001 validation rules
Charges Account<ChrgsAcct>
In conformance with the scheme
• No entries in this element are recognized.• If the content does not match the scheme, the entire
message (file) is rejected.
21
Other combinations, e.g. “Batch Booking” = “TRUE” and “Debtor Account/Type/Prtry” = “SIA” are rejected.
6.12.3. The following combinations of advices and booking type are possible:
Values in pain.001 Results
Element booking Element advice Booking Advice
True CND Collective Collective advice without details
True CWD Collective Collective advice with details
True NOA Collective No advice
False SIA Individual Individual advice with details
False NOA Individual No advice
UBS treatment Debit advices If instructions for advice management are supplied via pain.001 the advice control values from the master data are overridden.
Booking typeBydefaultcollectiveordersinapain.001arebookedcollectively(correspondstovalue‘true’inthe pain.001).
If single booking is desired (value false) each transaction (C-Level) is individually booked.
Please noteFor code SALA or PENS UBS always overrides the advice type (master data or instructions in pain.001).
Area in pain.001 Element Values UBS pain.001 validation rules
Advice controlDebtor Account/ Type/Prtry<DbtrAcct><Tp><Prtry>
• NOA• SIA• CND• CWD
• Combination of “Batch Booking” = “true” and “Debtor Account/Type/Prtry” = “SIA” is rejected.
Booking typeBatch Booking<BtchBookg>
• True• False
• If the Batch Booking element is not supplied, booking is similar to “true” (default value).
22
6.13. Management of reports in ISO 20022 standardThesamecodes(flags)asdescribedforadvicecontrol andintheprecedingsection6.13.alsoaffectgeneration of reports in ISO 20022 standard (camt. messages).
Using this attribute also overrides the master data for account reporting in the ISO 20022 standard. Details of this logic are described in the separate manual for reporting to ISO standard.
Combination of single booking and salary code “SALA/PENS”:
Values in pain.001 Resultincombinationwithsalaryflags“SALA/PENS”
Element “Advice” Element’Booking’ Advice Booking Comment
Empty TrueAccording to UBS master data – without details
Collective
Empty FalseAccording to UBS master data – without details
Single
CND TrueCollective advice without details
Collective
CWD TrueCollective advice without details
Collective Status Report with ACWC
NOA True No advice Collective
NOA False No advice Single
SIA False Advice without details Single
CND False
Combinations not allowed, transactions are rejectedCWD False
SIA True
23
The XML message “Customer Payment Status Report” (pain.002) provides information on the status of credit transfer orders placed with message type pain.001. There is a pain.002 status report for each pain.001 message placed.
NostatusreportisreturnedwithfileuploadviaE-Banking.The information on the status of the order or transaction is provided here by appropriate messages (errors or warnings) on the e-banking GUI.
7.1. Features of the status report• Thepain.002ismerelyaconfirmationofacceptanceof
the payment order. Completed order execution is confirmedbydebitingtheaccountoraccountreport(e.g. camt. or MT940).
• Pain.002 is always provided in the scheme in which the pain.001 was submitted.
• This status report is always generated and delivered on order placement for both positive and defective orders/single orders.
7. Order status and rejects (pain.002)
7.2. Overview of the possible status in reports
Status Description
ACCP Accepted Customer Profile)
Error-free orders (pain.001) are confirmedwithStatusAccepted(ACCP).
Syntax and semantic check was successful over all A-,B-andC-Levels(includingcustomerprofile[e.g.authorization check at the account stage]).
PART Partially Accepted
Orders with individual defective transactions are shown with status Partially Accepted (PART) as the order is correct in parts.The defective transactions from the order are shown as “rejected” (RJCT).
One or more B-Levels were not correct (at least 1 correct) or one or more C-Levels in a B-Level were not correct (at least 1 correct).
RJCT Rejected Invalid pain.001 messages and defectiveordersarenotifiedas“rejected” (RJCT).
In “Group Status”: the whole message is rejected. A-Level is not correct, or all B- or C-Levels are not correct. If “PmtInf”: all transactions at the corresponding B-Level are rejected.
ACWC Accepted with Change
Transactions which can be accepted by UBS but require a change for correct processing.
The whole message is accepted. Corresponds to current interpretation of “Warnings” and “Corrections”, e.g. value date correction, chained clearing numbers.
24
7.3. Warnings (ACWC)
7.4. Rejects (RJCT)
7.5. Order correctionsA correction of the rejected messages, orders and transactions(RJCT)isnotpossible;anewpain.001withthe corrected messages and transactions must always be submitted.
Affectedlevel Error cases (examples)
B-Level (Payment) • Executiondateisafterthecut-offtime
• Regrouping of B-Level where over 9,999 C-Levels (transactions) in one B-Level
C-Level (Transaction) • SEPA amount limit exceeded
Affectedlevel Error cases (examples)
Completefile • Error in scheme used• Message is not in conformance with the current version of XSD scheme• XMLfile(pain.001)cannotbevalidatedusingavalidXSDscheme• Rejection of entire message if there is a scheme violation within the message,
regardless of level and frequency (e.g. obligatory element not used)
A-Level (Group Header) • Totaling (A-Level) the number of transactions and/or amount is wrong• The same message ID and initiating party have already been submitted in the past
90 days
B-Level (Payment Information) • Field content is formally incorrect (e.g. debtor agent not UBS Switzerland AG)• Element not allowed or submitted without content
C-Level (Transaction) • Field content is formally incorrect (e.g. wrong creditor agent BIC)• Element not allowed or submitted without content
25
Duetothedifferentformatsininterbankpaymenttraffic(e.g. for payments in foreign currencies) and account statements not to ISO 20022 standard (e.g. MT940, paper), it is not possible to ensure that all data content can be
forwarded in full to recipients (truncation). The following dataelementsinparticularareaffected:
8. Limitation on forwarding information
Element XML Tag Use in non-ISO formats
End-to-EndIdentification <EndToEndId> Forwarding not possible, client is recommended to show ID in unstructured use purpose, if necessary (remittance information, unstructured)
Ultimate Debtor <UltmtDbtr> Forwarding not possible
Creditor Name and Postal Address • Country• Address Lines
<Cdtr><Nm></Nm><PstlAdr><TwnNm></TwnNm><Ctry></Ctry></PstlAdr></Cdtr>
Forwarding of max. 140 characters possible (name and addressaremappedtothe4x35unstructuredaddressfield)
Ultimate Creditor <UltmtCdtr> Forwarding not possible
Purpose Code <Purp> Forwarding not possible
Remittance Information, structured
<RmtInf> Structured information in remittance information mapped to 4 x 35 characters of unstructured remittance information
26
Term Description/DefinitionAOS Additional Optional Services
BIC BusinessIdentifierCode
camt Cash management messages
CGI Common Global Implementation
CNY Chinese Renminbi/Yuan
DME Data medium exchange
EBICS Electronic Banking Internet Communication Standard
EPC European Payment Council
ERP Enterprise Resource Planning
ESR Orange payment slip with reference number
FI Financial Institutions
FileAct See SWIFT Net (FileAct)
GBIC German Banking Industry Committee
IBAN International Bank Account Number
IIB Instituteidentification(newnameforBC–bankclearing)
ISO International Organization for Standardization
ISO 20022 Standardizationinfinance,suchaspaymenttransactionsandaccountreporting
IT Information Technology
LSV Direct debits
pacs Payments Clearing and Settlement messages
pain Payments Initiation messages
RDT Remote data transmission
RUB Russian ruble
Schema AnXMLschemedescribestheelementsandstructureofanXMLfile
SCT SEPA Credit Transfer
SDD SEPA Direct Debit
SEPA Single European Payment Area
SIX Swiss Infrastructure and Exchange
SPS Swiss Payment Standards
SWIFT Net (FileAct) SWIFT FileAct used for KeyPort customers
XML Extensible Markup Language (XML) is a language for presenting hierarchically structured dataastextfiles
XSD XMLSchemeDefinition=describeselementsandstructureofanXMLfile
ZE Creditor
ZD Debtor
9. Glossary
27
10. References
Title
UBS Implementation Guide forCredit Transfer message pain.001
The Implementation Guide for pain.001 establishes the technical aspects of using the Credit Transfer Message pain.001 with UBS.
UBS Implementation Guide pain.001
UBS Implementation Guide for Status Report pain.002
Thisdocumentcontainstechnicalspecificationsandinstructionsfortechnicalimplementation of the Payment Status Report pain.002 in conformance with the Swiss Recommendations (and accordingly with ISO 20022 standard)
UBS Implementation Guide pain.002
Swiss Business Rules Version 2.6 The Business Rules describe the requirements for business representatives of users,financialinstitutionsandsoftwaremanufacturersfromthepointofviewof the process. The following topics are covered:• Definitionanddescriptionofindividualbusinesscaseswiththerelevant
actors and messages used (payment types, report variants)• Presentation of message structures as overview, with further details of
individual structural elements• Description of the most important validation rules and error treatments
Swiss Business Rules
Swiss Implementation Guidelines for pain.001 Version 1.7.2
Swiss Implementation Guidelines for pain.002Version 1.1.1
The Implementation Guidelines are instructions for technical implementation of the standard and provide help in generating the individual message types. They describe the XML structures and validation rules in detail for national and cross-border payment transactions, including the Payment Status Report pain.002
Swiss Implementation Guidelines for pain.001
Swiss Implementation Guidelines for pain.002
28
Element Description
MessageIdentification End-to-endreferencetoidentifythemessage(file)unambiguously
Creation Date Time Date and time of creation of payment transaction message
Number Of Transactions Total amount of all individual transactions in the entire message
Control Sum Number of individual transactions in the message
Initiating Party Information on the party ordering the payment, i.e. debtor, or a party acting on behalf of the debtor
Appendix
11.1. Structure of pain.001
A pain.001 is structured as follows:
11.2. ThemostimportantelementsoftheA-Level–“GroupHeader”11.2.1. Definition
Message level
11. Structure and elements of a pain.001
The message structure breaks down as followsLevel AMessage level “Group Header"
Level BDebtor side, “Payment Information", information on debtor
Level CCreditor side, “Credit Transfer Transaction Information", information on creditor
A-Level(Group Header)
B-Level(Payment Information)
C-Level(Credit Transfer Transaction Information)
29
11.3. ThemostimportantelementsofaB-Level–“PaymentInformation”11.3.1. Definition
Debtor side, or information on debtor
Element Description
Payment Information Identification
Referenceforunambiguousidentificationofcollector
Payment Method Payment instrument, e.g. credit transfer
Batch Booking Indicator showing if this is a collective booking (true) or single booking (false)
Number Of Transactions Number of individual transactions within Payment Information Block
Control Sum Total of all individual transaction amounts within the Payment Information Block
Payment Type Information Transaction type, e.g. priority of payment, service level (agreement on how transaction is tobeprocessed,e.g.SEPA);typeofpayment(categorypurpose),localinstrument(e.g.ESR payment)
Requested Execution Date Desired execution date
Debtor (UBS master Data) Client for payment
Debtor Account IBAN
Debtor Agent Client’sfinancialinstitution
Ultimate Debtor Debtor,ifdifferentfromaccountholder
Charge Bearer Indication on billing charges for the payment order
Charges Account Additional account for separate debiting of charges
30
11.4. ThemostimportantelementsofaC-Level–“CreditTransferTransactionInformation”11.4.1. Definition
Creditor side, information on creditor
Element Description
PaymentIdentification Referencing of this transactionInstructionIdentification:uniquetransactionreferenceofdebtortotheircreditinstitutionEnd-to-endIdentification:uniquereferenceofcreditor.Thisreferenceisforwarded un-changed through the entire chain to the creditor.
Payment Type Information Transaction type, e.g. priority of payment, service level (agreement on how transaction istobeprocessed,e.g.SEPA);typeofpayment(categorypurpose),localinstrument(e.g. ESRpayment)
Amount Amount of credit transfer
Exchange Rate Information Optionalfield
Charge Bearer Indication on billing charges for the payment order
Check Instruction OptionalfieldforpaymentsbyBankcheck
Ultimate Debtor Debtor,ifdifferentfromaccountholder
Intermediary Agent Correspondent bank of receiving bank
Creditor Agent Creditor's bank
Creditor Beneficiary
Ultimate Creditor Creditor who is not the account holder
Instruction For Creditor Agent Instructions to receiving bank
Instruction For Debtor Agent Instructions to debtor bank
Purpose Type of payment
Remittance Information Reason for payment
31
UBS Switzerland AGP.O. Box8098 Zurich
ubs.com
Thispublicationisintendedforinformationonlyandisnotintendedasarecommendation,anofferorasolicitationofanoffer.Itisnottoberegardedaslegalortaxadvice.Beforemakingadecision,youshouldobtainrelevantprofessionaladvice.Please note that UBS reserves the right to alter its services, products or prices at any time without prior notice. Certainproductsandservicesaresubjecttolegalrestrictionsandcannotbeofferedworldwideonanunrestrictedbasis.Reproduction in whole or part is prohibited without prior permission from UBS.© UBS 2018. The key symbol and UBS are among the registered and unregistered trademarks of UBS. All rights reserved.