April 2018

ISO 20022UBS – transfers properly applied

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.