Technical Specifications

Transcription

1 essaging SWIFTRemit Directory 2.0 Technical Specifications These technical specifications provide detailed information about the SWIFTRemit Directory. They include descriptions of records, fields, and flags in the uploadable and downloadable files. 23 September 2011

2 SWIFTRemit Directory 2.0 Table of Contents.Preface About SWIFTRemit Directory Entities Definitions Working odel Data Entry Data Download Files Participant Data Product and Processing Data Point of Services Data Counterparties Data Guidelines and Rules Working Assumptions Population Rules and Guidelines Usage Rules Fields Value Setting Rules and Guidelines Examples of Data Structure Coding PD Record PP Record PS Record Y Record Legal Notices Technical Specifications

3 Preface Preface Purpose of this document This document provides the technical specifications of the SWIFTRemit Directory. The specifications contain the following information: an introduction to the Directory and the Directory application of the SWIFTRemit solution a definition of the entities, the roles for the Directory a technical description of the data structures supporting the reference data of the participants the rules and the usage guidelines for the upload and the download of the participants' reference data some example of the coding for the data structures for the participants Intended audience This guide is for operators and reference data managers that perform business and administration tasks using the SWIFTRemit Directory application. Significant changes The following table lists the changes to the SWIFTRemit Directory related to release 2.0. This table does not include editorial changes that SWIFT may have made to improve the usability and comprehension of the document. Addition of values in field PP.05 Payment Product Group for pension payment, modify or resend messages, and creditor validation capability Addition of one value in field PP.06 Service Level for the flash service level Addition of values in field PD.05 Participant Type for settlement service provider 3.2.2, "PP Data Structure" on page 17 "List of values for PP.05" on page , "PP Data Structure" on page , "PD Data Structure" on page 13 Related documentation SWIFTRemit Service Description SWIFTRemit Integration Guide SWIFTRemit Implementing FileAct Headers SWIFTRemit - Standards X essage Implementation Guidelines SWIFTRemit - Standards X essage Implementation Guidelines Business Examples Note Customers can find the latest version of most of these documents on swift.com > Support > Documentation. For more information, contact your SWIFT commercial manager. 23 September

4 SWIFTRemit Directory About SWIFTRemit Directory Description The SWIFTRemit Directory contains the reference data of the participants of the SWIFTRemit solution. This directory identifies the participants to the solution, their processing capabilities, and their point of services. Participants provide and update themselves their data. SWIFT controls, stores, and publishes the data according to the SWIFT Directories monthly publication cycle. Important The usage of this directory is restricted to the participants of the SWIFTRemit solution. Purpose The purpose of the SWIFTRemit Directory is to standardise and facilitate the files exchange between the participants to the solution. Accurate and up-to-date reference data helps the solution participants to build consistent and exhaustive payment instructions. The directory contributes to increase the overall service efficiency and the level of straight-through processing for remittances transactions. 1.1 Entities Definitions Types of participants Two types of participants A participant is a SWIFT user registered to the SWIFTRemit solution and can either be a service participant or a participant's agent. Service participant A service participant is a SWIFT registered user subscribed to the SWIFTRemit solution. nly service participants have direct access to the SWIFTRemit Directory and are directly involved in the data collection and data publication process with SWIFT. Code: SP Participant's agent A participant's agent is registered under the responsibility of the service participant and likewise for the SWIFTRemit Directory process. Participant's agent reference data are provided and maintained by the service participant responsible for their registration. Code: PA Related information For more information about eligibility criteria and participants roles, see the SWIFTRemit Service Description. 4 Technical Specifications

5 About SWIFTRemit Directory Reference Data anager Role The reference data manager is responsible for the data management. He handles the collection, the processing and the publication process of the reference data for the service Data Files Four different data types The data of the directory is a set of unique attributes qualifying a participant. The directory contains four reference data types: Data types Participant data Product and processing capabilities data Point of service data Counterparties data Code PD PP PS Y Participant data The participant data helps to identify the other participants in the service with their respective relationship: service participant or participant's agent. The attributes include items such as: processing BIC of the participant the person of contact the country of operation or the network address When relevant, it also includes the agent relationships with other participant It helps the participants building and maintaining the routing and processing table for their counterparts in the solution. Code: PD Product and processing capabilities data This data contains the products features and operating parameters supported by the participants of the solution. The attributes include items such as the following product features: the type of remittance product the service levels per product the currencies 23 September

6 SWIFTRemit Directory 2.0 The attributes also include operating parameters such as: upper limits: the maximum amount authorised by participant the validity period of a transaction not credited the transaction notification options The product and processing capabilities data facilitates the participants to establish service level agreement between counterparts. It helps participants to build and maintain the tables of the agreed service with counterparts that they can propose to their customers. It also helps to populate the payments instructions message with accurate data for a better straight-through processing rate. Some processing capabilities like the limits can also be used by the participants in their remittance transaction authorisation process, by checking payments instructions against the counterparts authorised limits. Code: PP Note The product and processing capabilities declared in the directory by a participant can differ from the one that they support with counterparts in the service as defined in their bilateral service level agreement. For instance, a service participant may declare in the directory that they support the delivery notification feature to mobile phone but does not necessarily offer that feature to all participants in the service. Point of service data The point of service data identifies the physical location where customers can be serviced by participants for sending or receiving remittances. It can be for instance a bank branch or an automated teller machine (AT). The attributes also include operating parameters such as: upper limits: the maximum amount authorised by participant the validity period of a transaction not credited the transaction notification options Code: PS Counterparties data The counterparties data is the list of counterparties that a participant has in the service. The business contracts are between a participant identifier and his counterparties. Code: Y 6 Technical Specifications

7 Working odel 2 Working odel Workflow Service Participants Reference Data anager y Data y Counterparties PD PP PS Y Data entry Participants data Product and Processing capabilities Points of Services y counterparties Upload in.txt format nline data entry Upload in.txt format SWIFTRemit Directory on swift.com y Data Data download - y data - y Counterparties - Full directory PD Participants data PP Product and Processing capabilities PS Points of Services Y y counterparties Service Participants Reference Data anager D What the reference data manager can do The reference data manager can provide data for: his own institution - y Data The reference data manager is responsible for the control and accuracy of the participant data. The reference data manager can upload data for participants identifier BIC11 belonging to the hierarchy of the BIC code of his own institution. If his BIC code is not the one of this parent institution, he can only upload data for the hierarchy below his own BIC. 23 September

8 SWIFTRemit Directory 2.0 Prerequisite He can only provide data for all BICs belonging to the parent institution if his swift.com address is linked to the parent BIC. the counterparties BICs - y Counterparties This is the list of counterparties that a participant has in the service. The business contracts are between a participant identifier and his counterparties. To use the SWIFTRemit Directory application, you first need to subscribe to the SWIFTRemit Directory using the e-forms on swift.com. Separate e-forms are available for the test service or the live service. Important During the subscription process, the participants are requested to assign a reference data manager. Functions of the application The SWIFTRemit Directory application has the following functions: Templates Upload Status Download y Data nline Help 2.1 Data Entry Two options You have two options to provide data: Upload data in.txt format In this case, you can use the Templates, Upload and Status functions Note The Templates function provides you with templates in icrosoft Excel format to facilitate the upload process. Upload data online, using the y Data nline function Note The y Data nline function is not available for the y Counterparties files. 8 Technical Specifications

9 Working odel Upload Data in.txt Format The Templates function Use the Templates function if you want to use the icrosoft Excel templates to provide the following data: y Data: the data of your own institution PD: participants' data PP: your own products and processing capabilities and the ones of your agents PS: your own points of services and the one of your agents y Counterparties Y: the list of counterparties The icrosoft Excel templates contain three macro buttons to perform the following tasks: to import data to validate data to generate a.txt file, required for upload The Upload function Use the Upload function to upload the files PD, PP, PS and Y) in the directory. nce uploaded, the files are validated automatically by the directory application. You can upload a file at any time during the month. Before the cut-off time nly the files uploaded and validated before the cut-off date of the month are guaranteed to be published for the current monthly publication cycle. After the cut-off time Files uploaded after the cut-off date are left for the publication cycle of the following month. The cut-off date for SWIFTRemit Directory is in line with the cut-off date of the other SWIFT Directories. The SWIFT Directories Publication Schedule is available on swift.com > Products & services > essaging > Reference Data > Resources centre > Useful linkspublication Schedule. When the participant data is modified, the reference data manager must not upload the entire data of the participant again. In this case, he can use a delta file containing only the modified, deleted, and new records. The Status function Use the Status function to verify the status of your upload tasks. In case of errors, click the link to consult the error message. You must first correct the error before uploading the file again. In case of syntax error, the file is rejected and the reference data manager is notified by . Note nly the validated files are published. 23 September

10 SWIFTRemit Directory Upload Data nline The y Data nline function Use the y Data nline function to update data record by record. This function is available for the PD, PP, and PS data types. Existing records can also be modified using this function. Note You can use the Help function at any time. 2.2 Data Download The Download function Concepts You can download three types of files from the SWIFTRemit Directory application: y Counterparties: your published counterparties data y Data: your own data Full Directory: the entire published Workers Remittances Directories The data is always structured around the following concepts: Data structure PD participant data PP: products and processing data PS: point of services data Environment Test Live Data content Version of files Full: contain all the records Delta: delta files contain only the records that have been modified since the previous publication. The version of the data available for Download is the last monthly publication. 10 Technical Specifications

11 Working odel y Counterparties Scope Use y Counterparties to download in.txt format the data of your counterparties. Data structure Data content PD PP PS Full Delta Test Live Example File naming convention of a PD file Test Live Full WR_PD_Y_TEST_DELTA_<Participant BIC8>_<Publication Date as yyyymmdd>.txt WR_PD_Y_<Participant BIC8>_<Publication Date as yyyymmdd>>.txt Delta WR_PD_Y_TEST_DELTA_<Participant BIC8>_<Publication Date as yyyymmdd>.txt WR_PD_Y_DELTA_<Participant BIC8>_<Publication Date as yyyymmdd>>.txt y Data Scope Use y Data to download in.txt format your own data. Data structure Data content PD PP PS Full Delta Test Live NA Example File naming convention of a PD file. Test Live Full WR_PD_TEST_DELTA_<Participant BIC8>_<Date as yyyymmdd>.txt WR_PD_FULL_<Participant BIC8>_<Date as yyyymmdd>>.txt Delta NA NA Full Directory Scope Use Full Directory to download in.txt format the data for the entire directory. The files are available at the date of publication according the SWIFT Directories Publication Schedule (5 to 7 days after the cut-off date for upload), 23 September

12 SWIFTRemit Directory 2.0 Data structure Data content PD PP PS Full Delta Test Live Example File naming convention of a PD file. Test Live Full WR_PD_TEST_DELTA_<Activation Date as yyyymmdd>.txt WR_PD_<Activation Date as yyyymmdd>>.txt Delta WR_PD_TEST_DELTA_<Activation Date as yyyymmdd>.txt WR_PD_DELTA_<Activation Date as yyyymmdd>>.txt 12 Technical Specifications

13 Files 3 Files 3.1 Participant Data File Naming Convention Filename for live PD data structure WR_PD_DELTA_<Participant Identifier>_<Activation Date as yyyymmdd>>.txt Filename for test PD data structure Examples WR_PD_TEST_DELTA_<Participant Identifier>_<Activation Date as yyyymmdd>.txt Live: WR_PD_DELTA_SBZAZAJJ_ txt Test: WR_PD_TEST_DELTA_SBZAZAJJ_ txt PD Data Structure Field descriptions Record's unique identifier: PARTICIPANT IDENTIFIER (PD.03) + RELATINSHIP BIC (PD.07) Ref Field name Description Status Data type Cardinality ax lengt h (in char) appin g PACS field (2) Usage rules and guidelines PD.00 RECRD KEY The unique key of the record in the file. The key consists of the IS country code and a sequential number of 6 digits 8 Participants must leave the field empty when they upload a new record Participants must populate the field with the value assigned by SWIFT when uploading a record for modification The format is <CC><NNNNNN> Where: <CC> is the IS country code of the participant <NNNNNN> is a unique sequence number assigned by SWIFT directories. PD.01 TAG Indicator of the type of record Alphabetic 2 The file Identifier tag value for a PD file is PD. 23 September

14 SWIFTRemit Directory 2.0 Ref Field name Description Status Data type Cardinality ax lengt h (in char) appin g PACS field (2) Usage rules and guidelines PD.02 DIFICATIN FLAG In the upload process: Alphabetic 1 In the upload process A addition request modification flag as requested by the participant In the publication process: State of the record for the current publication cycle compared to the previous publication cycle modification request D deletion request In the publication process A Added record odified record D Deleted record (3) U unchanged record PD.03 PARTICIPANT IDENTIFIER Identifier of a participant in the service 11 yes Used as part of the key in the data structure to identify a participant to the service and the PD file in particular. In the case of service participant PD.05="S" the value must be a BIC8 or a BIC11. In the case of a participant agent PD.05="A" the value must be a BIC or a proprietary identifier with less than 11 characters Used to identify FI in the pacs messages acting in the payment/ settlement process as debtor agent, creditor agent and intermediaries like Instructed/ instructing Agent, Instructing/ instructed Reimbursement Agent, Third Reimbursement Agent (see pacs structures). PD.04 PARTICIPANT NAE Name of the participant 70 yes Used to identify the name of the participant for the administration of the service. PD.05 PARTICIPANT TYPE Participant type can be either SERVICE or AGENT according the participation criteria defined for the SWIFTRemit Service Description Alphabetic 1 Value="S" if the participant acts as a service participant. Value="A" if the participant acts as agent of service participant. Value="P" if the participant acts as settlement service provider Value="" if the participant acts as both service participant and settlement service provider 14 Technical Specifications

15 Files Ref Field name Description Status Data type Cardinality ax lengt h (in char) appin g PACS field (2) Usage rules and guidelines PD.06 SWIFT USER CATEGRY The field must be present and must reflect the SWIFT user category (1) 4 The service participant should indicate in that field the type of membership that they have as a SWIFT user. See the Eligibility Criteria section of the SWIFTRemit Service Description. PD.07 RELATINSHIP BIC That field defines the relationship with a service participant. In the case that the Participant is an AGENT, the field must link with the BIC8 of the registering participant BICIdentifier 11 ne AGENT can have several relationships with SERVICE. Nevertheless a participant must create a record for each of its agent even if already registered with another participant If the PARTICIPANT TYPE is SERVICE, then the relationship BIC must be equal to the BIC of the participant identifier in PD.03. PD.08 CITY Name of city or place of the participant operation for the service ax35text 35 yes Used to identify the city of the participant for the administration of the service. PD.09 CUNTRY CDE IS country code of the participant operation for the service CountryCode 2 yes Used to identify the country of operation of the participant for the administration of the service. PD.10 ADDRESS Building name, detailed building information, street name, and number. The order of the information in these 4 fields depends on accepted practice for the individual country (part1) ax70text 70 yes Used to identify the address of operation of the participant for the administration of the service. PD.11 PSTCDE Address of the participant operation ax16text 16 yes Used to identify the participant post code and location for the administration of the service. PD.12 SUBSCRIPTIN DATE Date from which the entry is valid (defined as the initial operational date from the service subscription/ renewal date) Date (YYYYDD ) 8 Date of subscription of the SWIFT user to the service Date fields have a length of 8 characters, structured in this format YYYYDD, where: YYYY = year = month DD = day 23 September

16 SWIFTRemit Directory 2.0 Ref Field name Description Status Data type Cardinality ax lengt h (in char) appin g PACS field (2) Usage rules and guidelines PD.13 EXPIRATIN DATE Date up to which the entry is valid (defined as the end of operational date from the initial service subscription/ renewal date) Date (YYYYDD ) 8 Date of expiration of the subscription of the SWIFT user to the service. PD.14 CNTACT NAE 1 Name of the person of contact within the organisation of the participant in charge of the relationship with SWIFT 70 For service participant, the person described must be the reference data manager. PD.15 CNTACT PHNE 1 Phone of the contact person (See field PD.09) (4) 70 PD.16 CNTACT E-AIL 1 of the contact person (See field PD.09) 70 PD.17 CNTACT NAE 2 Name of the person of contact within the organisation of the participant in charge of the relationship with SWIFT for the service 70 PD.18 CNTACT PHNE 2 Phone of the contact person (See field PD.09) (4) 70 PD.19 CNTACT E- AIL 2 of the contact person (See field PD.09) 70 PD.20 SWIFTNET ADDRESS The SWIFTNet address or Distinguished Name (DN) that the participant will be using the exchange FileAct messages with counterparts in the service ax70text 70 (1) For more information about user categories, see swift.com > about SWIFT > Community > SWIFT user categories (2) pacs002/004/008 (3) A record marked as deleted is automatically removed from the publication file at the next publication cycle. (4) International ITU format 16 Technical Specifications

17 Files 3.2 Product and Processing Data File Naming Convention Processing rule The files are processed as incremental updates. Filename for live PP data structure WR_PP_DELTA_<Participant Identifier>_<activation date as yyyymmdd>.txt Filename for test PP data structure Examples WR_PP_TEST_DELTA_<Participant Identifier>_<activation date as yyyymmdd>.txt Live: WR_PP_DELTA_SBZAZAJJ_ txt Test: WR_PP_TEST_DELTA_SBZAZAJJ_ txt PP Data Structure Field descriptions Record's unique identifier: PARTICIPANT IDENTIFIER (PP.03) + PARTICIPANT RELATINSHIP BIC (PP.04) + PAYENT PRDUCT GRUP (PP.05) + SERVICE LEVEL (PP.06) + PRCESSED CURRENCY (PP.07). See 4.2.1, "Records Relationship and Uniqueness" Ref Field name Description Status Data type Cardinality ax lengt h (in char) appin g on PACS (1) field Usage rules and guidelines PP.00 RECRD KEY The unique key of the record in the file. The key consists of the IS country code and a sequential number of 6 digits 8 Participants must leave the field empty when they upload a new record Participants must populate the field with the value assigned by SWIFT when uploading a record for modification or deletion The format is: <CC><NNNNNN> where <CC> is the IS country code of the participant and <NNNNNN> is a unique sequence number assigned by SWIFT directories. PP.01 TAG Indicator of the type of record for the service Alphabetic 2 The file Identifier tag value for a PP file is PP. 23 September

18 SWIFTRemit Directory 2.0 Ref Field name Description Status Data type Cardinality ax lengt h (in char) appin g on PACS (1) field Usage rules and guidelines PP.02 DIFICATIN FLAG In the upload process: modification flag as requested by the participant In the publication process: State of the record for the current publication cycle compared to the previous publication cycle Alphabetic 1 In the upload process: A addition request modification request D deletion request U unchanged In the publication process: A Added record odified record D Deleted record (2) U Unchanged record PP.03 PARTICIPANT IDENTIFIER Identifier of a participant in the service 11 yes Should relate to the participant identifier (PD.03) in the PD file having registered the product and processing capabilities. PP.04 PARTICIPANT RELATINSHIP BIC That field defines the relationship with a Service Participant. In the case that the Participant is an AGENT, the field must link with the BIC8 of the registering participant BICIdentifier 11 Should relate to the relationship BIC (PD.07 ) in the PD file having registered the product and processing capabilities. PP.05 PAYENT PRDUCT GRUP Code indicating payment product group within the service level under which payments can be executed by the participant. See the "List of values for PP.05" on page This field must be completed with the list of the payment product categories supported for processing by a participant in the service. When creating payment instructions for a remittance transaction to a counterparty, the participants should make sure that they only indicate a payment product category supported by its counterparty. 18 Technical Specifications

19 Files Ref Field name Description Status Data type Cardinality ax lengt h (in char) appin g on PACS (1) field Usage rules and guidelines PP.06 SERVICE LEVEL Code indicating preagreed level of service under which payments can be executed by the institution. List of values limited to WR01, WR02, WR03, WR04 at the moment for SWIFTRemit Standard, Urgent, Instant, and Flash SLA (3) ax4text 4 yes This field must be completed with the list of the service level supported by a participant in the service. When creating payment instructions for a remittance transaction to a counterparty, the participants must make sure that they only indicate in the service level field a service level supported by its counterparty. The service level selected by the participant should be populated in the data structure ref 1.22 Service Level in the field Proprietary ref 1.24 (See pacs 008 structures for remittances). PP.07 PRCESSED CURRENCY Currency per product category supported for processing by the participant CurrencyCod e 3 yes This field must be completed with a list of structured values reflecting the currencies processed by a participant per product category in the service. When creating payment instructions for a remittance transaction to a counterparty, the participants must make sure that they only instruct a currency supported by its counterparty per product category as indicated in the list. PP.08 RECEIVING UPPERLIIT aximum value per payment that a receiving participant can authorise in the service scheme according their international/ regional obligations in the country of operation Numeric 8 yes This field must be completed with a list of structured values reflecting the maximum amount processed by the participant per transaction, per currency and per product category in the service. When creating payment instructions for a remittance transaction to a counterparty, the participants should make sure that they only instruct an amount smaller or equal to the maximum amount supported by its counterparty per product category and per currency as indicated in the list. 23 September

20 SWIFTRemit Directory 2.0 Ref Field name Description Status Data type Cardinality ax lengt h (in char) appin g on PACS (1) field Usage rules and guidelines PP.09 AXIU VALIDITY DURATIN aximum validity for a payment not credited to the beneficiary from the date of payment receipt by the receiving bank (number of business days) Numeric 3 yes Value must be set by the participants according their international/regional obligations in the country of operation if any. The reference data environment should provide the data structure to support the publication of data. In absence of specific national obligations, the following guidelines are recommended for transparency: For product group 1 (account based) If a non-stp payment cannot be repaired, then it must be returned within 7 days by the creditor agent/ultimate creditor agent. For product group 2 (non-account based) A transaction not delivered to the beneficiary should be returned by the creditor agent/ ultimate creditor agent after 45 days. perational usage: at each settlement cycle with its counterparties in the service, a check should be done by participants, acting as a creditor agent for the remittances payments not credited to beneficiaries is the current date is beyond number of business days from the settlement date for the creditor agent for the transaction. PP.10 CREDITR NTIFICATIN PTIN Notification options supported by the participant towards creditor TEL, SS, EAIL, FAX, ADDRESS, HDEL ax12text [1..6] 65 yes See code field (ref 2.47) in the instruction for creditor agent data structure (ref 2.46) in the pacs. 008 subset for the service. When creating payment instructions for a remittance transaction to a counterparty, the participants must make sure that they only instruct a notification option supported by its counterparty as indicated in the list. 20 Technical Specifications

21 Files Ref Field name Description Status Data type Cardinality ax lengt h (in char) appin g on PACS (1) field Usage rules and guidelines PP.11 SETTLEENT TIE ZNE Time zone of settlement for the participant 10 Defined in reference to GT. For example, the settlement time zone value for a participant in Paris would be GT (1) pacs. 004 (2) a record marked as deleted is automatically removed from the publication file at the next publication cycle. (3) WR01, WR02, WR03 are payments processed in the swift.remit.fast FileAct store-and-forward service. WR04 is for real-time payment processed in the swift.remit.flash FileAct real-time service. List of values for PP.05 For PP.05, the list of values are limited to: GRP1 account based remittance product GRP2 non-account based remittance product GR1 account based remittance product with creditor account identified with mobile phone GR2 non-account based remittance product with creditor identified with mobile phone only at the moment CVL1 creditor validation capability for group 1 (creditor account details) CVL2 creditor validation capability for group 2 (creditor identifier details) RSN1 modify by resend for product group 1 (modification of creditor account details) RSN2 modify by resend for product group 2 (modification creditor identifier details) DF1 modify for product group 1 payment DF2 modify for product group 2 payment PEN1 pension payment for product group 1 payment PEN2 pension payment for product group 2 payment 3.3 Point of Services Data File Naming Convention Processing rule The files are processed as incremental updates. Filename for live PS data structure WR_PS_DELTA_<Participant PS BIC>_<activation date as yyyymmdd>.txt 23 September

22 SWIFTRemit Directory 2.0 Filename for test PS data structure Examples WR_PS_TEST_DELTA_<Participant PS BIC>_<activation date as yyyymmdd>.txt Live: WR_PS_DELTA_SBZAZAJJ_ txt Test: WR_PS_TEST_DELTA_SBZAZAJJ_ txt PS Data Structure Field descriptions Record's unique identifier: PS BIC (PS.03) + PRPRIETARY IDENTIFIER (PS.04 ) + WNER IDENTIFIER (PS.05) + WNER RELATINSHIP BIC (PS.06). See 4.2.1, "Records Relationship and Uniqueness" Ref Field name Description Status Data type Cardinality ax lengt h (in char) appin g PACS (1) field Usage rules and guidelines PS.00 RECRD KEY The unique key of the record in the file. The key consists of the IS country code and a sequential number of 6 digits 8 Participants must leave the field empty when they upload a new record. Participants must populate the field with the value assigned by SWIFT when uploading a record for modification or deletion. The format is: <CC><NNNNNN> where <CC> is the IS country code of the participant and <NNNNNN> is a unique sequence number assigned by SWIFT directories. PS.01 TAG Indicator of the type of record for the service Alphabetic 2 The file Identifier tag value for a PS file is PS. PS.02 DIFICATIN FLAG In the upload process: modification flag as requested by the participant in the publication process: Alphabetic 1 In the upload process: A Addition request odification request State of the record for the current publication cycle compared to the previous publication cycle. D Deletion request In the publication process: A Added record odified record D Deleted record (2) U Unchanged record 22 Technical Specifications

23 Files Ref Field name Description Status Data type Cardinality ax lengt h (in char) appin g PACS (1) field Usage rules and guidelines PS.03 PS BIC BIC11 Code of the PS (BIC11 used by the participant in the service to identify a branch in its retail network and enabled for the service) BIC11Identifie r 11 yes At least one of the 2 fields PS.03 or PS.04 must be filled. The value should be mapped on the Branch Identifier field of the Branch Identification Data Structure in the pacs. 008/004/002 subset for remittances for debtor agent and creditor agent. PS.04 PRPRIETARY IDENTIFIER Proprietary Identifier of the PS (used when a participant has a special branch identifier) (2) 35 yes When the PS BIC code is not present, the Proprietary PS Identifier should be mapped on the Branch Identifier field of the Branch Identification Data Structure in the pacs. 008/004/002 subset for remittances from debtor agent and creditor agent. PS.05 WNER IDENTIFIER Identifier of the participant owner of the PS 11 yes Should relate to the participant identifier (PD.03) in the PD file owner of the point of service. PS.06 WNER RELATINSHIP BIC Defines the relationship BIC with the service participant owner of the PS BICIdentifier 11 Should relate to the relationship BIC (PD.07) in the PD file owner of the point of service. PS.07 NAE Name of the PS ax35text 35 yes To facilitate the straight-through processing, when PS.03 and PS. 04 are empty it is recommended to populate the value of that field in the Branch Name field of the Branch Identification data structure in the pacs. 008/004/002 subset for remittances. PS.08 CITY Name of city or place of the PS ax35text 35 yes To facilitate the straight-through processing, when PS.03 and PS. 04 are empty it is recommended to populate the value of that field in the TownName field of the Branch Identification data structure in the pacs.08/004/002 subset for remittances. PS.09 CUNTRY CDE IS country code of the PS CountryCode 2 yes To facilitate the straight-through processing, when PS.03 and PS. 04 are empty it is recommended to populate the value of that field in the Country field of the Branch Identification data structure in the pacs.008/004/002 subset for remittances. The Country code of a PS cannot be different from the Country Code declared by the participant owner of that PS in its PD record. 23 September

24 SWIFTRemit Directory 2.0 Ref Field name Description Status Data type Cardinality ax lengt h (in char) appin g PACS (1) field Usage rules and guidelines PS.10 ADDRESS Address of the PS ax70text 70 yes To facilitate the straight-through processing, when PS.03 and PS. 04 are empty it is recommended to populate the value of that field in the Street Name field of the Branch Identification data structure in the pacs.08/004/002 subset for remittances. PS.11 PSTCDE Address of the institution head quarters (derived from the BIC Directory) ax16text 16 yes To facilitate the straight-through processing, when PS.03 and PS. 04 are empty it is recommended to populate the value of that field in the PostCode field of the Branch Identification data structure in the pacs.08/004/002 message subset for remittances. PS.12 PS.13 PS.14 PS.15 PENING HURS N PENING HURS TUE PENING HURS WED PENING HURS THU Business opening hours in the day (onday) Business opening hours in the day (Tuesday) Business opening hours in the day (Wednesday) Business opening hours in the day (Thursday) ax12text [0..3] ax12text [0..3] ax12text [0..3] ax12text [0..3] The business hours must be coded with a begin time and an end time with 2 digits for hours and 2 digits for minutes with : as separator between hours and minutes and / as separator between begin time and end time hh:mm/hh:mm up to 3 time ranges can be defined for a day. For example, business hours from 8H30 to 16H30 are coded as <TAB>08:30/16:30<TAB> PS.16 PENING HURS FRI Business opening hours in the day (Friday) ax12text [0..3] 36 PS.17 PENING HURS SAT Business opening hours in the day (Saturday) ax12text [0..3] 36 PS.18 PENING HURS SUN Business opening hours in the day (Sunday) ax12text [0..3] Technical Specifications

25 Files Ref Field name Description Status Data type Cardinality ax lengt h (in char) appin g PACS (1) field Usage rules and guidelines PS.19 PS.20 CNTACT NAE 1 CNTACT PHNE 1 PS.21 CNTACT E- AIL 1 Name of the person of contact for the PS Phone of the contact person (cfr field 12) of the contact person (See field 12) (3) Fields provided by participants to their counterparties in sending or receiving countries to improve quality and transparency of service to customers (those fields are not transported with the pacs.008/004/002 message subset for remittances). PS.22 CNTACT NAE 2 Name of the person of contact for the PS 70 PS.23 CNTACT PHNE 2 Phone of the contact person (See field 12) (3) 70 PS.24 CNTACT E- AIL 2 of the contact person (See field 12) 70 PS.25 SUPPRTED LANGUAGES Identification of the languages supported by the PS to serve customers (coded with IS country code) ax3text [1..n] 40 List of languages coded as a list 3-characters code from the IS639-2 table. iso639-2/is-639-2_utf-8.txt. PS.26 PERATIN TIE ZNE Time zone of operation of the PS ax10text 10 Defined in reference to GT. For example, the time zone value for a PS in Brussels "GT (1) pacs.008 (2) A record marked as deleted is automatically removed from the publication file at the next publication cycle. (3) International ITU format 3.4 Counterparties Data File Naming Convention Filename for live Y data structure WR_Y_DELTA_<BIC8>_<ActivationDate>.txt Filename for test Y data structure WR_Y_TEST_DELTA_<BIC8>_<ActivationDate>.txt Examples Live: WR_Y_DELTA_SBZAZAJJ_ txt Test: WR_Y_TEST_DELTA_SBZAZAJJ_ txt 23 September

26 SWIFTRemit Directory Y Data Structure Fields descriptions Ref Field name Description Status Data type Cardinality ax lengt h (in char) Usage rules and guidelines Y.01 RECRD KEY The unique key of the record in the file. 8 Participants must leave the field empty when they upload a new record. Participants must populate the field with the value assigned by SWIFT when uploading a record for modification or deletion. The format is: <CC><NNNNNN> where <CC> is the IS country code of the participant and <NNNNNN> is a unique sequence number assigned by SWIFT directories. Y.02 TAG Indicator of the type of record for the service Alphabetic 2 The file Identifier tag value for a Y file is Y. Y.03 DIFICATIN FLAG In the upload process: modification flag as requested by the participant In the publication process: State of the record for the current publication cycle compared to the previous publication cycle. Alphabetic 1 In the upload process: A Addition request odification request D Deletion request In the publication process: A Added record odified record D Deleted record U Unchanged record Y.04 PARTICIPANT IDENTIFIER Identifier of a Service participant in the service 11 For a service participant PD. 05= S the value must be a BIC8 or a BIC11. Y.05 CUNTERPAR TY IDENTIFIER Identifier of your Counterparties in the service 11 The counterparties should be identified with the same value that is used in the PD file (Participant identifier). As counterparties are always service participant (PD.05= S ) the value must be a BIC8 or a BIC Technical Specifications

27 Guidelines and Rules 4 Guidelines and Rules 4.1 Working Assumptions Data Accuracy Rule The data provided by the participants in the reference data structures (PD, PP, PS) must be accurate and reflect the exact status and the capabilities of the participant at the moment of publication Country of peration for Participants Rule and guideline for service participants A service participant may operate the service in several countries. Participant must create one data structure per country of operation. Entries should be created in the PD and PP files for each operation instance of a participant in a specific country. Guideline for participant agents A participant agent may only operate in one country, the country registered by its related service participant Service Conditions and the Published Data Rule The service conditions agreed between the service participants can be different from the reference data published by the service participants in the directory, reflecting the participant service capabilities at the time of publication. Service conditions agreed between the service participants must be based on published capabilities but are agreed in bilateral outside the service framework. Example It doesn't mean because a service participant indicates that it supports INSTANT service level that it has an agreement for that service level with all the other service participant registered for the service. 23 September

28 SWIFTRemit Directory Population Rules and Guidelines Records Relationship and Uniqueness PD records The participant file (PD) must contain only one record per Service Participant or Participant Agent. A service participant or a participant agent record is identified by a unique key made up of 2 fields : PARTICIPANT IDENTIFIER PD.03 and RELATINSHIP BIC PD.07. PP records If a new PD record uploaded by a service participant contains a key value equal to an existing key of a PD record in the published PD file of the SWIFTRemit Directory it will be rejected. If a modified PD record uploaded by a service participant contains a key value that does not equal an existing key of a PD record in the published PD file of the SWIFTRemit Directory it will be rejected. A service participant or a participant agent owns one or several product and processing records (PP), meaning that the pair of fields PARTICIPANT IDENTIFIER PP.03 and PARTICIPANT RELATINSHIP BIC PP.04 must always contain a pair of values pointing to an existing record with unique key PD.03 + PD.07 in the published PD file of the SWIFTRemit Directory. If a new or modified PP record uploaded by a service participant contains values in the PP.03 and PP.04 fields that does not equal an existing key of a PD record in the published PD file of the SWIFTRemit Directory it will be rejected. A product and processing (PP) record is identified by a unique key made up of the following 6 fields: PARTICIPANT IDENTIFIER (PP.03) + PARTICIPANT RELATINSHIP BIC (PP.04) + PAYENT PRDUCT GRUP (PP.05) + SERVICE LEVEL (PP.06) + PRCESSED CURRENCY (PP.07). PS records If a new PP record uploaded by a service participant contains values equal to an existing key in the published PP file of the SWIFTRemit Directory it will be rejected. If a modified PP record uploaded by a service participant contains values not equal to an existing key in the published PP file of the SWIFTRemit Directory it will be rejected. A service participant or a participant agent owns zero or several point of services records (PS), meaning that the pair of fields WNER IDENTIFIER PS.05 and WNER RELATINSHIP BIC PS.06 must always contain a pair of values pointing to an existing record with unique key PD.03 + PD.07 in the published PS file of the SWIFTRemit Directory. If a new PS record uploaded by a service participant contains a key value in the PS.05 and PS.06 fields that does not equal an existing key of a PD record in the published PD file of the SWIFTRemit Directory it will be rejected. If a modified PS record uploaded by a service participant contains a key value in the PS.05 and PS.06 fields that does not equal to an existing key of a PD record in the published PD file of the SWIFTRemit Directory it will be rejected. 28 Technical Specifications

29 Guidelines and Rules A point of services (PS) record is identified by a unique key made up of the following 4 fields: PS BIC (PS.03) + PRPRIETARY IDENTIFIER (PS.04 ) + WNER IDENTIFIER (PS.05) + WNER RELATINSHIP BIC (PS.06). If a new PS record uploaded by a service participant contains values equal to an existing record key in the published PS file of the SWIFTRemit Directory it will be rejected. If a modified PS record uploaded by a service participant contains values not equal to an existing record key in the published PP file of the SWIFTRemit Directory it will be rejected TAB Delimited Format Rule The data structures must be encoded in tab-delimited format (fields are delimited by <TAB> character and records by a Carriage Return/Line Feed character <CR/LF>. Fields with multiple value should be delimited by <CA> Supported Character Set Rule The text fields of the data structure must only be populated with characters from the SWIFT II characters plus character File Naming Conventions Rule The file naming conventions as described for the three data structures (participant data, product and processing capabilities, and point of services) must be followed by the service participant to insure consistency in processing by the SWIFT Service Administrator and their counterparties participating to the service. Files submitted to the directory application with errors in the file naming convention will be rejected by the Service Administrator Submission Rule Rule The three participant files (participant data, product and processing capabilities, and point of services) must be created and uploaded in the SWIFTRemit Directory on swift.com before the cut-off date to be published the month after. Related information 2, "Working odel" 23 September

30 SWIFTRemit Directory Population Rules for Participant Agent Rules The service participants must register the details of the participants operating in the service, as their agent, under their responsibility. The service participant must create and update the reference data files for their agents. A service participant can have several agents. The service participants are responsible for the accuracy of the data provided for their participant agents. The provided reference data must reflect the participant agent capabilities at the time of publication. A participant agent could be registered by several service participants in the service with different product and processing capabilities and therefore a set of reference data files should be defined for each relationship of participant agent with a service participant Assignment of a Reference Data anager by the Participant Rule SWIFT recommends that service participants assign a reference data manager within its organisation to supervise the accuracy of the data provided in the files for the SWIFTRemit Directory. The details of that person must be provided in the participant data structure and will be used by the SWIFT Service Administrator as the single point of contact for the participant concerning the SWIFTRemit Directory and related matters SWIFT Disclaimer on Participant Data Accuracy Rule The SWIFTRemit Directory service controls the syntax of the files but not the semantics. SWIFT is not liable for the data provided by the participants For example, the BIC field syntax provided by a participant can be correct in terms of format, but the BIC may be non-existing or expired Notification of Errors in Files to Participants Rule The SWIFTRemit Directory application notifies the rejection of a file to the contact person of the participant in case of processing error. 4.3 Usage Rules New Information onthly Check Rule The participants must check on a monthly basis the new package of files to be downloaded from the SWIFTRemit Directory on swift.com and updates the relevant in-house table that they have from their counterparties participating to the service. 30 Technical Specifications

31 Guidelines and Rules Selective Usage of Relevant Data by Participant Rule The participants must download from the swift.com the files that are relevant for their processing relationship (reference data of the counterparties for which they have a bilateral agreement to operate in the service) and have been updated if necessary since the last publication cycle (the file naming convention and the file creating date facilitate the relevant selection for the participant) In-house Database Update Rule When new relevant reference data have been downloaded by the participant, the participant must trigger a process for updating the in-house database used for processing the remittances transactions in the solution with the relevant data. 4.4 Fields Value Setting Rules and Guidelines Participant Data Rules The publication of the participant data in the SWIFTRemit Directory is compulsory for all solution participants. The fields marked as mandatory in the participant data structure should be populated by the participant and maintained accurate as long as the participant remains registered in the solution. If the RELATINSHIP BIC field PD.07 is equal to the BIC in the PARTICIPANT IDENTIFIER field PD.04 and if the PARTICIPANT TYPE field is S, the participant is a service participant. If the RELATINSHIP BIC field is populated with the BIC of another participant, then the participant is agent of the service participant indicated in the RELATINSHIP BIC. If the PARTICIPANT IDENTIFIER field PP.03 is of BIC format then participant cannot be a service participant but a participant agent. An agent is in relationship with one and only one service participant Point of Services Data Rules and guidelines The publication of point of services data in the Workers Remittance Directory is optional to the solution participant but highly recommended for non-account based products support in the service (Payment Product Group PP.05 equal to GRP2). PS data can be related to one and only one participant (service participant or participant agent). The WNER IDENTIFIER field PS.05 and the WNER RELATINSHIP BIC PS.06 of a PS record should relate to one unique participant record in the PD file with the same value populated in the PARTICIPANT IDENTIFIER field PD.03 and the RELATINSHIP BIC field PD.07. PS registered by a participant must be located in the same country as its owner participant. PS registered by a participant can be enabled for sending and/or receiving remittances services. PS 23 September