ISO 20022 Standard 18 Translation Guide - BACS
TRANSLATION GUIDEISO 20022/BacsVERSION 1.1 29 Nov 2017
TRANSLATION GUIDEISO 20022/BacsCONTENTS1DOCUMENT INFORMATION41.11.21.3VERSION HISTORYDOCUMENT REVIEWERSCOPYRIGHT DDOCUMENT PURPOSEDOCUMENT STRUCTURESCOPEREFERENCED DOCUMENTS556673BACS OVERVIEW83.13.23.33.43.53.6INTRODUCTIONHIGH LEVEL PAYMENTS PROCESSBACS PROCESS MESSAGESBACS DC MESSAGE FLOWDD MESSAGE FLOWADDITIONAL INFORMATION8881213134TRANSLATION RODUCTIONCONTRASEND TO END ITEM IDENTIFICATIONFURTHER OPTIONAL ISO 20022 MESSAGE CONTENTBACS MANDATORY FIELDSIMPLEMENTATION SCOPETRANSLATION LAYER RESPONSIBILITIESBACS CHARACTER SET & CONVENTIONSDATE MAPPINGMAPPING TO ISO 20022 GROUP HEADER MESSAGE IDENTIFICATION141415151516161718185STANDARD 18 TRANSLATION – FILE STRUCTURES & DATA205.1INTRODUCTION202 VERSION 1.1 29 NOV 2017
TRANSLATION GUIDEISO 20022/Bacs5.25.35.45.55.65.7INPUT FIELDSSUBMISSION STRUCTUREOUTPUT FIELDSOUTPUT STRUCTUREATTRIBUTE MAPPINGFIELDS 9 AND 112021222222246CUSTOMER GRADE PAYMENTS – ATIONS2525257PAYMENTS - RATIONS2828288BANK GRADE TRANSACTIONS (INCLUDING NS343510OTHER MESSAGING AGE FLOW CATALOGUE39B.BACS OUTPUT - TRANSACTION CODE TO MESSAGE MAPPING41C.GLOSSARY433 VERSION 1.1 29 NOV 2017
TRANSLATION GUIDEISO 20022/Bacs1 DOCUMENT INFORMATION1.1VERSION HISTORYVERSIONDATEDESCRIPTIONV1.004 Jan 2017Version for publication. The main changes are the rewording of certainsections in chapters 1 & 2.V1.129 Nov 2017[1] Includes recalls and reversals.[2] Attribute translation guide sections have been removed as they aresuperseded by the accompanying Translation Specification.1.2DOCUMENT REVIEWERSSTAKEHOLDERACTIONSTAKEHOLDERACTIONNeil Cannon (Bacs)PAndy Hollingdale (Bacs)AVince Burr (VocaLink)RBharat Mistry (Payments UK Standards)RAction: P – Producer; C – Contributor; R – Reviewer; A - Authoriser; I - Information only1.3COPYRIGHT STATEMENTAll rights reserved.The copyright in this document is owned by Bacs Payment Schemes Limited (Bacs). All material,concepts and ideas detailed in this document are confidential to Bacs. This document shall not beused, disclosed or copied in whole or in part for any purposes unless specifically approved by Bacs.4 VERSION 1.1 29 NOV 2017
TRANSLATION GUIDEISO 20022/Bacs2 INTRODUCTION2.1BACKGROUNDBacs’ role is to own, develop, enhance and preserve the integrity of automated payments andpayment related services. It promotes access, efficiency, innovation and best practice in paymentsand payment related services in the interests of all users of automated payments services. Bacs hasbeen maintaining the integrity of payment related services since 1968, and is committed to ensuringthat access to its products meets tomorrow’s demands.Bacs payments messages use a proprietary format known as Standard 18 which comprises both arecord structure and a field structure within those records. Defined length fields predetermine theinformation that can be provided within the payment. This message format supports Bacs’ highlyefficient bulk overnight payment processing. Other historic Bacs product differentiators include: Direct access to the scheme for payment originators (as opposed to via a payment serviceprovider [PSP])A processing model that assumes a successful outcome and provides messaging services (aka AServices) for exception processing e.g. to notify originators of returns (ARUCS, ARUDD) andchanged account details (AWACS, ADDACS)The ability to recall both individual payments and payment groups.The creation of one debit and multiple credits by Bacs DC, and vice versa for DD, which facilitatesreconciliation (of returned/rejected items) by exception.ISO 20022 is the international messaging standard of choice in the payments industry and is beingused increasingly in the UK. ISO 20022 is more than simply a message format. It is a businessprocess supported by the exchange of standardised messages which are derived from a datadictionary of standard data components. The Payment Strategy Forum (PSF) has the desire for thewhole UK payments eco-system to adopt ISO 20022 end to end to align with global standards andprovide the basis for modernisation.Bacs' stated aim is to adopt ISO 20022 standards where it is appropriate, and a suitable business casecan be made.Recognising these factors, Bacs sees value in providing guidance for organisations that wish to accessBacs services using an ISO 20022 message interface. This document achieves that by providing theframework for translation between Standard 18 and ISO 20022 message formats. The translationdescribed within this document has been jointly defined by Bacs, VocaLink and Payments UKStandards. This document assumes a familiarity with Bacs processes and message flows.2.2DOCUMENT PURPOSEThe purpose of this document is to describe how Bacs services in their current form can be used byorganisations (payment originators, aggregators and PSPs) that use ISO 20022 for their paymentsprocesses. To achieve this purpose a translation is required. This document acts as the guide to thattranslation and should be considered as best practice for organisations implementing their own5 VERSION 1.1 29 NOV 2017
TRANSLATION GUIDEISO 20022/Bacstranslations. An accompanying ISO 20022/Bacs translation pack [Ref 06] that consists of bothmessage and attribute level mappings, and accompanying schemas, is provided on the Bacs web site.In addition to this translation guide and the accompanying translation pack, usage and/orimplementation of the translation requires reference to the Bacs documentation set.Bacs recognises that some organisations, for example those with international customers, willalready have developed their own translations in this space, and welcomes dialogue with interestedparties to harmonise best practice. Please contact us at: access@bacs.co.uk2.3DOCUMENT STRUCTUREThe remainder of this document is structured as follows: Chapter 3 provides an overview of the Bacs payments processChapter 4 describes translation considerationsChapter 5 outlines Standard 18 file structures and dataChapters 6 to 8 address the translation of payments process messagesChapter 9 addresses the translation of AUDDIS process messagesChapter 10 addresses the translation of AWACS and ADDACS process messagesAppendix A is a catalogue of the Bacs message flowsAppendix B highlights how the Bacs transaction codes map to the message flows describedwithin this documentAppendix C is both a glossary terms and also deciphers all acronyms used within this document.2.4SCOPE2.4.1IN SCOPEA principle behind the translation described in this document is that it can be implemented with nochanges to the business as usual (BAU) Bacs service.All of the in scope Bacs messages are listed in Appendix A.To achieve a pragmatic, fit for purpose translation without over-complicating the solution, thefollowing are in scope: The input into Bacs via a translation from ISO 20022 of:o Bacs Direct Credits with a transaction code of 99 (Direct Credit).o Direct Debits with a transaction code of 17 (Direct Debit – regular collection).Single file submissions (sfs)Input file submissions with a single:o Day section (i.e. single processing day [spd], which may be future dated), ando Account section.6 VERSION 1.1 29 NOV 2017
TRANSLATION GUIDEISO 20022/Bacs2.4.2OUT OF SCOPEWhilst this translation guide has been provided and published by Bacs, Bacs has no plan or businesscase to implement its own version of this translation (or elements of it) for general usage.To avoid overburdening the translation with avoidable legacy constructs, the following are designedto be out of scope: Optional ISO 20022 attributes that are not supported by BacsThe input into Bacs via a translation from ISO 20022 of:o Bacs Direct Credits with transaction codes other than 99 (Direct Credit).o Direct Debits with transaction codes other than 17 (Direct Debit – regular collection).o Intervention instructions (e.g. extraction, re-input, amend date and reversal), which willcontinue to be supported by the Payment Exception Management (PEM) service (see[Ref 05]).Multifile submissions (mfs) i.e. A submission of payments for more than one service user will beachieved by separate single file submissions (sfs).Input file submissions with more than one:o Day section (i.e. Multiprocessing day [mpd] is out of scope)o Account sectionThe DDIC (Direct Debit Indemnity Claim) process, because it is a predominantly manual processthat is not considered to justify message translationThe input and output of credit card items (E1 and E2) and the translation of output Standard 29files.The input and output of Automated Teller Records (07). These transactions are no longerprocessed by Bacs.Unused/legacy payment types e.g. credit card debits and refunds, and ATM collections. 2.5REFERENCED DOCUMENTSREFTITLEPRODUCED BYVERSIONDATE01Bacs Service Functional SpecificationVocaLink1.2003 Mar 201602Bacs Electronic Funds Transfer, File Structures (PN5011)VocaLink3.1003 Oct 201603Bacs Messaging File Structures (PN7871)VocaLink1.8003 Oct 201604Bacs Service XML Specification and Advices fromMessaging Engine and Payment Engine (PN6336)VocaLink3.007 May 201505Bacs Members Guide Volume 4 - Processing ManagementVocaLink2.9005 Jul 201706ISO 20022/Bacs Translation Specification & schemasBacsLatest7 VERSION 1.1 29 NOV 2017
TRANSLATION GUIDEISO 20022/Bacs3 BACS OVERVIEW3.1INTRODUCTIONThis chapter provides an overview of Bacs payment process messaging. Bacs non-payment messageflows are covered later in this document.3.2HIGH LEVEL PAYMENTS PROCESSA high level view of the clearing and settlement of payments in the Bacs service is shown below.3.3BACS PROCESS MESSAGESIn addition to Standard 18 messages, certain Bacs processes rely on Bacs reports which are alsoavailable in XML format. There is also an ADDACS format. The diagram below shows the messageflow formats of customer and bank grade transactions.8 VERSION 1.1 29 NOV 2017
TRANSLATION GUIDEISO 20022/BacsThe table below lists the Bacs message flows and indicates the message format. The numbering usedin this table is used throughout this document to reference these message flows.9 VERSION 1.1 29 NOV 2017
TRANSLATION GUIDEISO 20022/BacsFLOWNOBACS MESSAGEDIRECTIONMSG FORMATFROMTOPayment1aDirect creditsISO BacsStandard 18SUBacsPayment1bDirect debitsISO BacsStandard 18SUBacsPayment2Customer grade Input reportBacs ISOReport/XMLBacsSUPayment3aCleared creditsBacs ISOStandard 18BacsDest PSPPayment3bCleared debitsBacs ISOStandard 18BacsDest PSPPayment3cCredit contrasBacs ISOStandard 18BacsSU PSPPayment3dDebit contrasBacs ISOStandard 18BacsSU PSPPayment3eCleared credit reversalsBacs ISOStandard 18BacsSU PSPPayment3fBacs ISOStandard 18BacsSU PSPPayment4aISO BacsStandard 18Dest PSPBacsPayment4bISO BacsStandard 18Dest PSPBacsPayment4cCleared debit reversalsBank grade credit returns(ARUCS items)Bank grade debit returns(ARUDD items)Credit recallsISO BacsStandard 18Dest PSPBacsPayment5aBank grade Input reportBacs ISOReport/XMLBacsDest PSPPayment5bCredit return contrasBacs ISOStandard 18BacsDest PSPPayment5cDebit return contrasBacs ISOStandard 18BacsDest PSPPayment6aCleared credit returnsBacs ISOStandard 18BacsSU PSPPayment6bUnapplied credit notifications(ARUCS report)Bacs ISOReport/XMLBacsSUPayment6cCleared debit returnsBacs ISOStandard 18BacsSU PSPPayment6dUnapplied debit notifications(ARUDD report)Bacs ISOReport/XMLBacsSUPayment6eCleared credit recallsBacs ISOStandard 18BacsSU PSPAWACS1a(see Payment 1a)AWACS3a(see Payment 3a)AWACS4dAWACSISO BacsAWACS overADDACSDest PSPBacsAWACS6fAWACSBacs ISOReport/XMLBacsSUADDACS1b(see Payment 1b)ADDACS3b(see Payment 3b)ADDACS4eDDI cancellationsISO BacsADDACSDest PSPBacsADDACS4fDDI amendmentsISO BacsADDACSDest PSPBacsADDACS6gDDI cancellationsBacs ISOReport/XMLBacsSUADDACS6hDDI amendmentsBacs ISOReport/XMLBacsSU10 VERSION 1.1 29 NOV 2017
TRANSLATION GUIDEISO 20022/BacsThe contents of this table are repeated in Appendix A with the addition of: Mapping to ISO 20022 messagesReferences to Bacs documentation.Within the diagrams in this document the following convention has been adopted:The two diagrams that follow depict the message flows between payment originators, Bacs, and PSPsfor the clearing of Bacs Direct Credit (DC) and Direct Debit (DD) payments, respectively.In the diagrams below, Destination PSP refers to the destination of the cleared output message (asopposed to the flow of funds, for example, in a DD collection scenario). For credits, the destinationPSP is the PSP that holds the payee’s bank account. For direct debits, the destination PSP is the PSPthat holds the payer’s bank account.11 VERSION 1.1 29 NOV 2017
TRANSLATION GUIDEISO 20022/Bacs3.4BACS DC MESSAGE FLOWThe diagram below highlights the message flows of a Bacs Direct Credit scenario. These flows areexplored in more detail in later chapters within this document.12 VERSION 1.1 29 NOV 2017
TRANSLATION GUIDEISO 20022/Bacs3.5DD MESSAGE FLOWThe diagram below highlights the message flows of a Direct Debit collection scenario. These flowsare explored in more detail in later chapters within this document.3.6ADDITIONAL INFORMATIONThe Bacs service processes transactions in sterling. The currency in all value messages will thereforebe “GBP”.13 VERSION 1.1 29 NOV 2017
TRANSLATION GUIDEISO 20022/Bacs4 TRANSLATION CONSIDERATIONS4.1INTRODUCTIONKey translation considerations to be considered are as follows: 4.2ContrasEnd to end item identificationFurther optional ISO 20022 message contentMandatory fieldsBacs character set.CONTRASBacs is probably unique in its use of contras. A contra transaction is essentially a transactionsumming a set of direct debits (a debit contra) or a set of direct credits (a credit contra), and isapplied to the originator’s account. It is a consequence of the Bacs Direct Corporate Access (DCA)model, and was designed at a time before networks were available for general purpose dataexchange. The originator of the batch of payments provides both “sides” of the payment process forcentral processing.This translation guide assumes that contras will be generated in the translation layer.A contra looks similar to an ordinary payment, but its purpose and processing rules differ (forexample, a contra cannot be declined or returned). A contra has service user’s reference (field 10)set to “CONTRA” on input and “BACS” on output. Credit contras are debits that with a transaction14 VERSION 1.1 29 NOV 2017
TRANSLATION GUIDEISO 20022/Bacscode (field 04) of “17”, mapped to pacs.003. Debit contras are credits with a transaction code of“99”, mapped to pacs.008.The originating and destination account details of contras are always the same. For customer gradecontras the (originating and destination) account details are those of the originator. For bank gradecontras the (originating and destination) account details are those of the PSP’s suspense account.In cases where the contra amount is too great for the amount field (Field 8, see Input fields in thenext chapter), multiple contras are required.4.3END TO END ITEM IDENTIFICATIONISO 20022 items have end to end item identifiers. The intended usage of the end-to-endidentification is for reconciliation or to link tasks relating to the transaction. Bacs does not have adirect equivalent, and there is no Bacs message field that could be used/re-purposed to pass such anend to end item identifier through the clearing process.There is a need for related transactions on the return leg to be linked back to the originatingtransaction. This must be achieved in the translation layer. It is anticipated that the translation layerwill retain the end to end item identifier of the inward flows, and subsequently populate the end toend item identifier on corresponding/returning outward flows. The latter will be achieved bymatching the (original) originating and destination account details, the amount and the service user’sreference.The originator’s end to end item reference number will typically only be known to the destinationPSP in scenarios where the two parties in question use the same translation layer implementation.Where the originator’s end to end item identifier is not known to the destination PSP, considerationshould be given to any processes that may require transactions to be traceable/identifiablethroughout the lifecycle, for example, when dealing with customer enquiries.4.4FURTHER OPTIONAL ISO 20022 MESSAGE CONTENTBacs messages predetermine the information that can be passed. Extended message content (forexample, remittance details over and above service user’s reference) cannot therefore be passedthrough Bacs to a destination PSP.4.5BACS MANDATORY FIELDSCertain Bacs message flows require mandatory fields to be passed that may not typically be availablein the corresponding ISO 20022 message. An example is the AWACS message (see chapter 8) fromthe destination PSP to Bacs that requires the Bacs processing date and amount of the original item.This will be achieved by extending the ISO 20022 message using the Supplementary Data construct.15 VERSION 1.1 29 NOV 2017
TRANSLATION GUIDEISO 20022/Bacs4.6IMPLEMENTATION SCOPEEach organisation implementing a translation layer can determine which messages they wish totranslate e.g. they could choose to translate all or a subset of the Standard 18 messages, whilst usingexisting Bacs reports/XML for the operation of remaining processes. The picture below shows theinteraction with Bacs of the key stakeholders in the payments process.4.7TRANSLATION LAYER RESPONSIBILITIESA representation of responsibilities of a translation layer is shown below.Key responsibilities of a translation layer are described in the table below.16 VERSION 1.1 29 NOV 2017
TRANSLATION GUIDEISO 20022/BacsRESPONSIBILITYJUSTIFICATIONCreation of credit/debit contras (see Contras, above)Contras are not used in the ISO 20022 model but arerequired by BacsTracking the flow of individual items throughout theend to end processOtherwise the linkage of payment items risks beinglost between the ISO 20022 message flows and BacsRetention of details (for the duration of respectiveprocesses) relating to an item that is identified by anend to end item identifier (e.g. the mappingbetween end to end item identifier and originatingand destination account details, amount and SUreference) that support ISO 20022 message flowsbut are not always available, when required, inexisting Bacs message flowsTo support reconciliation or to link tasks relating tothe transactionValidation of ISO 20022 inputs using standard ISO20022 status messagesMandatory requirement for the technical validationof input messagesProvision of an audit trail of translated messagesOperational requirement for interface integritySecurity/integration with BacsOperational requirement for interface integrityThe routing of files to and from Bacs is achieved by BAU mechanisms and depends on the recipient'schannel and configuration. Banks use ETS (Enhanced Transmission Service) or STS (SWIFTNetTransmission Service). Service users who submit directly use Bacstel-IP. (The Department of Work &Pensions [DWP] is an exception in that it has access to a bank grade channel.) Unattended reportcollection is also an output mechanism.The management of which PSPs and originators require their messages to be translated to ISO 20022will in principle be achieved through existing Bacs channels and routing mechanisms includingunattended report collection.4.8BACS CHARACTER SET & CONVENTIONSIn Standard 18, only the following characters are allowed: A–Z (Alpha
Bacs' stated aim is to adopt ISO 20022 standards where it is appropriate, and a suitable business case can be made. Recognising these factors, Bacs sees value in providing guidance for organisations that wish to access Bacs services using an ISO 20022 message interface. This document achieve s that by providing the
Deutsche Bank Foreword Most banks will have already started their journey as they migrate to the new messaging standard of ISO 20022, while Market Infrastructures (MIs) push ahead with their own preparations. Of course, all this will not happen overnight: the ISO 20022 migration will
payments service, which will incorporate the ISO 20022 message format. 11 . The Federal Reserve Banks and The Clearing House have expressed intentions to adopt ISO 20022 for the Fedwire Funds Service and CHIPS, but the scope, m
In addition, the Official Corporate Action Event Identification (CA ID or COAF as it is known in ISO 20022) is a unique event reference for the event, and is assigned by a designated body within each market. DTC publishes the Official Corporate Action Event Identification on DTC eligible securities on its ISO 20022 messages.
Nacha, ISO 20022, XML, ASC X12 820, ASC X12 835, ASC X12 Data Segments, UN/EDIFACT, Nacha-endorsed banking conventions ISO 20022 Proprietary, Nacha, Debit Card ISO 8583 ISO 8583 ISO 8583 Nacha Payment Messaging Standard Same Day Immediate 24/7/365 Same Day for Debit Card, 1-2 Days for
The DIN Standards corresponding to the International Standards referred to in clause 2 and in the bibliog-raphy of the EN are as follows: ISO Standard DIN Standard ISO 225 DIN EN 20225 ISO 724 DIN ISO 724 ISO 898-1 DIN EN ISO 898-1 ISO 3269 DIN EN ISO 3269 ISO 3506-1 DIN EN ISO 3506-1 ISO 4042 DIN
ISO 10381-1:2002 da ISO 10381-2:2002 da ISO 10381-3:2001 da ISO 10381-4:2003 da ISO 10381-5:2001 da ISO 10381-6:1993 da ISO 10381-7:2005 ne ISO 10381-8:2006 ne ISO/DIS 18512:2006 ne ISO 5667-13 da ISO 5667-15 da Priprema uzoraka za laboratorijske analize u skladu s normama: HRN ISO 11464:2004 ne ISO 14507:2003 ne ISO/DIS 16720:2005 ne
ISO 10771-1 ISO 16860 ISO 16889 ISO 18413 ISO 23181 ISO 2941 ISO 2942 ISO 2943 ISO 3724 ISO 3968 ISO 4405 ISO 4406 ISO 4407 ISO 16232-7 DIN 51777 PASSION TO PERFORM PASSION TO PERFORM www.mp ltri.com HEADQUARTERS MP Filtri S.p.A. Via 1 Maggio, 3 20060 Pessano con Bornago (MI) Italy 39 02 957
Service Level Agreement For any other Business Broadband Service, We’ll aim to restore the Service within 24 hours of you reporting the Fault. Where we need a site visit to resolve a Fault, we only do site visits on Working Days during Working Hours (please see definitions at the end of the document). Service Credits are granted at our discretion date by which Exclusions (applicable to all .
