WIXLIB

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 characters upper case only)0–9 (Numeric characters). (Full stop)& (Ampersand)/ (Slash)- (Hyphen)Blank spaceThe Bacs character set does not allow lower case alphabetic characters. When a lower case alphacharacter is input into Bacs, it is converted to a blank space. If lower case characters are includedwithin the fields being mapped to Standard 18 fields 9 to 11 (service user’s name, service user’sreference and destination account name, respectively), the translation will convert these to uppercase.17 VERSION 1.1 29 NOV 2017

TRANSLATION GUIDEISO 20022/BacsBacs will publish schemas to facilitate mapping to Standard 18. The schemas will validate data typeand any defined data formatting/pattern.Bacs Standard 18 amount fields are the amount in pence. The translation will map between theStandard 18 format and the respective ISO 20022 amount format.4.9DATE MAPPINGStandard 18 date fields are typically in the format bYYDDD where b is a blank space, YY is the last twodigits of the year, DDD is Julian date with preceding zeros if necessary e.g. 5 January 2004 is“ 04005”. Julian dates run sequentially starting from 1 January as 001 and finishing on 31 Decemberas 365 (or 366 in a leap year).ISO date fields have the following format: YYYY-MM-DDIn ISO 20022, the “execution” date of a payment equates to the “value” date. Bacs operates a 3 dayclearing cycle. Bacs payment files contain processing date (in the user header label 1 [UHL1]). In the3 day clearing cycle, the customer receives value one working day after this processing date. Thetranslation will manage the conversion of the value date, known in ISO 20022 as the execution orsettlement date and Bacs processing date. A consideration for the originator is that the Bacspayment file must be submitted (on the “entry” date which is at least) two working days in advanceof the value date. The 3 (working) day cycle effectively consists of (three consecutive working days)the entry date, the processing date and the value date. The Time element of an ISO 20022 Date Timefield is not mapped to Bacs.4.10MAPPING TO ISO 20022 GROUP HEADER MESSAGE IDENTIFICATION4.10.1INTRODUCTIONMessage Identification is a mandatory field in every ISO 20022 Group Header. The following threepatterns are used, respectively, to generate a unique ISO 20022 Group Header MessageIdentification by means of concatenating appropriate Bacs fields:4.10.2 Bacs output Bacs Input report (Other) Bacs reportBACS OUTPUTCONCATENATED FIELDSSIZEADDITIONAL INFORMATIONValue date8See section 4.9 (Date mapping); format YYYYMMDDBank code3UHL1Stream number2UHL1File section number4HDR118 VERSION 1.1 29 NOV 2017

TRANSLATION GUIDEISO 20022/BacsCONCATENATED FIELDS4.10.3SIZEISO message suffix3e.g. 004 (for pacs.004)Credit Debit Indicator4CRDT or DBIT (required to achieve uniqueness for, for example, pacs.007)BACS INPUT REPORTCONCATENATED FIELDS4.10.4ADDITIONAL INFORMATIONSIZEValue date8Originator SUN6Submission reference number20ADDITIONAL INFORMATIONSee section 4.9 (Date mapping); format YYYYMMDD(OTHER) BACS REPORTCONCATENATED FIELDSSIZEReport generation date8Originator SUN6Report sequence number2019 VERSION 1.1 29 NOV 2017ADDITIONAL INFORMATIONformat YYYYMMDDWhere one exists

TRANSLATION GUIDEISO 20022/Bacs5 STANDARD 18 TRANSLATION – FILE STRUCTURES& DATA5.1INTRODUCTIONThis chapter describes both the Bacs Standard 18 input and output file structures and data, and thefundamental mapping between Standard 18 data and ISO 20022 constructs.5.2INPUT FIELDSA representation of Bacs Standard 18 fields input into both credit and debit payment instructions isprovided below.FIELDNAME01destination sorting code02destination accountnumber03destination account type04transaction code05originating sorting code06originating accountnumber07free formatNOTENot usedFor Bacs salary payments contains a cross-reference (generatedby an HMRC hashing algorithm) that links to the employer'sPAYE (Pay As You Earn) RTI (Real Time Information) return toHMRC.For returns contains the return reason code.08amount in pence09service user's nameWill be set to spaces for bank grade contras in this translation10service user's referenceISO 20022 has both an Instruction Identification and aTransaction Identification. This translation maps the SUreference to Instruction Identification i.e. intended as an end toend (as opposed to a transitory) reference11destination account namePayer’s account name for a DDI20 VERSION 1.1 29 NOV 2017

TRANSLATION GUIDEISO 20022/Bacs5.3SUBMISSION STRUCTUREThe input structure of a Standard 18 payment submission is provided below.CATEGORYHeadersITEMDESCRIPTIONVOL1Volume header label 1Includes submitter SUN e.g. bureau numberHDR1Header label 1Includes originator SUNHDR2Header label 2UHL1User header label 1Input itemsTrailersFURTHER INFORMATIONIncludes processing date, currency codePayment instructions or DDIsEOF1End of file label 1Repeats information in HDR1EOF2End of file label 2Repeats information in HDR2UTL1User trailer label 1Includes value totals and countsPayment instructions must be grouped into input file submissions each with a single day and accountsection where: Day section is all payment instructions in a payment file that have the same processing dateAccount section is all customer grade payment instructions in a day section that have the sameoriginating account details. For bank grade service users, all items in a day section form a singleaccount section.To simplify the translation, constraints on each ISO 20022 submission of a group of payments (thatwill translate to a Bacs input file) will be that: Each submission must be limited to one Day section (known as single processing day [spd]) andone Account section of either only credits or only debits. This will be defined as a validation rulewithin the translation layer.Each submission must be for a single service user number (known as single file submission [sfs]).Where a submitter (e.g. a bureau) submits for many service users, this must be achieved withsingle file submissions where VOL1 owner identification identifies the submitter and HDR1service user number identifies the service user.21 VERSION 1.1 29 NOV 2017

TRANSLATION GUIDEISO 20022/Bacs5.4OUTPUT FIELDSThe Bacs transaction processing service prepares items for output where they have not beenrejected during processing. The original item is output with some additional information.FIELD5.5NAMENOTE12error code/indicatorSee error codes in PN5011 [Ref 02]13originator’s authorised identifying numberOriginator SUN. The service user number in thepayment file (HDR1 field 3 characters 6 to 11) in whichthis payment instruction was originally input to Bacs.14Bacs output reference numberSee PN5011 [Ref 02]15originator’s AUDDIS statusSee PN5011 [Ref 02]OUTPUT STRUCTUREThroughout each processing day, the Bacs service outputs a “daily run” to Standard 18 output streamcontaining both credit and debit value items for that stream.These data records are all for the current processing day. The following shows the structure of theoutput.CATEGORYHeadersITEMDESCRIPTIONVOL1Volume header label 1HDR1Header label 1HDR2Header label 2UHL1User header label 1Output itemsTrailers5.6FURTHER INFORMATIONIncludes sequential file section numberPayment instructions or DDIsEOF1/EOV1End of file or volume label 1If last file of day EOF, else EOVEOF2/EOV2End of file or volume label 2If last file of day EOF, else EOVUTL1User trailer label 1Contains counts and value totals for bothcredits and debitsATTRIBUTE MAPPINGA representation of the translation between the Standard 18 payment fields for Bacs Direct Creditsand Direct Debits and ISO 20022 attributes is shown in the table below.A Bacs Direct Credit: Debits the account of a PSP that sponsors the originating service user Credits a Bacs (reachable) destination.A Direct Debit: Credits the account of a PSP that sponsors the originating service user Debits a Bacs (reachable) destination.22 VERSION 1.1 29 NOV 2017

TRANSLATION GUIDEISO 20022/BacsISO 20022 Message ElementFor Bacs Direct CreditsFor Direct DebitsBacs output reference number, Field 14Bacs output reference number, Field 14transaction code, Field 04transaction code, Field 04Payment IdentificationTransaction IdentificationPayment Type InformationLocal Instrument/ ProprietaryDebtorIdentificationHDR1 SUN & originator’s authorisedidentifying number, Field 13Debtor AccountIdentificationOther/ IdentificationNameoriginating account number, Field 06destination account number, Field 02service user's name, Field 09destination account name, Field 11originating sort code, Field 05destination sorting code, Field 01destination sorting code, Field 01originating sort code, Field 05Debtor AgentFinancial Institution IdentificationClearing System MemberIdentificationMember IdentificationCreditor AgentFinancial Institution IdentificationClearing System MemberIdentificationMember IdentificationCreditorIdentificationHDR1 SUN & originator’s authorisedidentifying number, Field 13Creditor AccountIdentificationOther/ IdentificationNamedestination account number, Field 02originating account number, Field 06destination account name, Field 11service user's name, Field 09free format, Field 07free format, Field 07amount in pence, Field 08amount in pence, Field 08amount in pence, Field 08amount in pence, Field 08service user's reference, Field 10service user's reference, Field 10Regulatory ReportingDetails/ InformationAmountInstructed Amount (pain)Interbank Settlement Amount(pacs)Remittance InformationStructuredCreditor Reference InformationReference23 VERSION 1.1 29 NOV 2017

TRANSLATION GUIDEISO 20022/Bacs5.7FIELDS 9 AND 11The table below shows how Standard 18 input fields 9 and 11 are populated in different messagetypes. This information (excepting the Comment field) is taken from the Bacs Electronic FundsTransfer, File Structures (PN5011) [Ref 02].MESSAGE TYPEFIELD 9FIELD 11CHARACTER POSITIONSCHARACTER POSITIONS47 - 6483 - 100Cu

whole UK payments eco-system to adopt ISO 20022 end to end to align with global standards and provide the basis for modernisation . 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