5 February 2021 Administrator Guide

Financial Standards LibraryVersion 3.9.05 February 2021

Administrator Guide

Copyright © 2021 Axway

All rights reserved.

This documentation describes the following Axway software:

Axway Financial Standards Library 3.9.0

No part of this publication may be reproduced, transmitted, stored in a retrieval system, or translated into any human or computer language, in any form or by any means, electronic, mechanical, magnetic, optical, chemical, manual, or otherwise, without the prior written permission of the copyright owner, Axway.

This document, provided for informational purposes only, may be subject to significant modification. The descriptions and information in this document may not necessarily accurately represent or reflect the current or planned functions of this product. Axway may change this publication, the product described herein, or both. These changes will be incorporated in new versions of this document. Axway does not warrant that this document is error free.

Axway recognizes the rights of the holders of all trademarks used in its publications.

The documentation may provide hyperlinks to third-party web sites or access to third-party content. Links and access to these sites are provided for your convenience only. Axway does not control, endorse or guarantee content found in such sites. Axway is not responsible for any content, associated links, resources or services associated with a third-party site.

Axway shall not be liable for any loss or damage of any sort associated with your use of third-party content.

Contents

1 Overview 6Introduction to Financial Standards Library 6Financial Standards Library contents 6Terminology used in this document 7

2 SEPA mappings 8National format to SDD mapping 9About SDD management in Financial Standards Library 9Transformation to SDD 10Operating modes 12Financial Integration mandate repository 15Configure B2Bi for national format to SDD 19Test SDD with sample data 22

CFONB to SCT mapping 25About CFONB to SCT mapping 25CFONB flows 25Configure B2Bi for CFONB to SCT 29Test flows with sample data 29

DTAUS0 to SCT mapping 30About DTAUS0 to SCT mapping 30Configure B2Bi for DTAUS0 to SCT 31Test flows with sample data 32

SCT to PSR mapping 33About SCT to PSR mapping 33Functional terminology 34SCT-PSR mapping method 36PSR versions 37Configure SCT to PSR maps 39Configure B2Bi for SCT to PSR 41Functional implementation 42Compute Payment Status 44Technical objects 45

PSR generation (SCT/SDD to PSR mapping: FF01 control) 46Overview 46Structure of the SCT/SDD input data 46Structure of the PSR output data 47SCT-PSR and SDD-PSR mapping methods 48

AxwayFinancial Standards Library 3.8.0 Administrator Guide 3

3 SWIFT mappings 50Cash Management MT to MX Transformation SR11_01 51About Cash Management MT to MX mapping 51Configure B2Bi for Cash Management MT to MX 52Test flows with sample data 53

Credit Transfer MT to MX Transformation SR08 54About Credit Transfer MT to MX mapping 54Configure B2Bi for Credit Transfer MT to MX 55Test flows with sample data 56

Credit Transfer MX to MT Transformation SR08 57About Credit Transfer MX to MT mapping 57Configure B2Bi for Credit Transfer MX to MT 58Test flows with sample data 58

4 Payments messages 59X9.37 60Configure B2Bi for X9.37 61

BAI2 62Configure B2Bi for BAI2 63

ISO 8583 64Configure B2Bi for ISO 8583 64

NACHA 65Configure B2Bi for NACHA 65

5 Financial Integration Reference Data 67About Financial Integration Reference Data 68Usage 68Origin and update of information 68

Using Financial Integration Reference Data (Custom-Functions) 69General information 69BBAN functions 70IBAN and BIC functions 74Extraction from IBAN 80Bank information search 84Version information 88Error handling functions 89Compatibility functions 91

Importing and updating reference data 94Configure B2Bi for the update of reference data 94Reference data file 95Result of import 95Supported Reference Data files 96File name recognition 96IBAN Structure file 98


Combined SWIFTRef files 98Reference Data structure information 99Financial Integration Reference Data database schema 99File to table mapping 102

Banque de France file compiler tool 111Overview 111Usage 111Examples 111

Analysis & migration tool 113Overview 113Command line help 113Analysis mode 114Replacement mode 117

6 Financial components 123Introduction to XML Encryption/Decryption JMC 123Configuration on B2Bi 123Prerequisites 123B2Bi UI configuration 124

Register JMC on B2Bi 124


1 Overview

Introduction to Financial Standards LibraryAxway Financial Standards Library contains libraries of tools, formats and maps. These libraries are used by Integration-Processes to execute operations such as control or transformation on the content of the messages exchanged throughout the Financial Integration platform. The Integration-Processes are run by Integrator or B2Bi.

l Tools libraries enable the management of reference data and provide a set of functions using the reference data to validate, enrich, or transform data structure carried by the messages exchanged throughout the Financial Integration platform. The main reference data enable the identification of players within the financial area: banks, large corporates, market infrastructure, and so on. The tools libraries are used to check the validity of bank identifiers or to map local identifications to international ones for such objects as account numbers, bank identifiers, and so on.

l Format libraries enable the validation of messages against financial format standards published by standardization organizations such as ISO (ISO 20022 format), SWIFT (FIN format), European Payment Council (EPC for SEPA format), and so on. The format libraries use the functions delivered within the tools libraries to execute the compliance validation of specific data structure of the message such as the Business Identifier Code (BIC), the country code, the Bank Account Number, and so on. The payments messages format libraries enable the processing of X9.37, BAI2, ISO 8583, and NACHA information for banks.

l Map libraries enable the transformation of messages from one financial format standard to another. They use the functions delivered within the tools libraries to execute the transformation and compliance validation of data structures carried by the messages such as the Basic Bank Account Number (BBAN) to the International Bank Account Number (IBAN).

Financial Standards Library is delivered with B2Bi Client.

Financial Standards Library contentsAxway Financial Standards Library contains the following installable libraries:

l The mandate data management library.

l The national payment format to SEPA Direct Debit format transformation library.

l The SCT mapping libraries enable the transformation of national payment formats to the SEPA Credit Transfer (SCT) format. These libraries also support the SEPA migration use case for corporate customers.


1 Overview

l The SCT to PSR mapping libraries enable the processing at the bank side of the SEPA Credit Transfers received from the customers and the construction of Payment Status Report (PSR) according to the business practices of the bank.

l The payments messages format libraries enable the processing of X9.37, BAI2, ISO 8583, and NACHA information for banks. X9.37 defines the file format that banks use to exchange images of checks. The BAI2 file format is a specialized and standardized set of codes used for cash management by the Bank Administration Institute (BAI). ISO 85831 is the International Organization for Standardization standard for systems that exchange electronic transactions made by cardholders using payment cards.

l The Reference data libraries enable the management of the BIC/IBAN-related reference data. These libraries enable you to populate the referential data repository with source files coming from SWIFT, SWIFTRef and "Banque de France". Beyond the management of the repository, a set of functions is provided to be used by Financial Standards Library as well as by in-house integration developments. These functions enable the validation of IBAN and BIC as well as the transformation of BBAN to IBAN, and so on.

Terminology used in this documentThis document often refers to national formats. An example of a national format is CFONB (Comité Français d'Organisation et de Normalisation Bancaires) for France. The samples supplied with Axway Financial Standards Library relate to the CFONB standard.


2 SEPA mappings

This chapter describes the libraries in Axway Financial Standards Library that are dedicated to the management of SEPA payment messages.

This version of Axway Financial Standards Library contains three SEPA-oriented libraries:

l Two sets of libraries that support the SEPA migration use case on the corporate side:

o The SDD Management libraries that fulfill the service of Mandate data management and the transformation from national payment formats to SEPA Direct Debit format

o The SCT mapping libraries that fulfill the service of transformation from national payment formats to SEPA Direct Credit format

l One set of libraries that support the Payment Initiation use case on the bank side:

o The SCT to PSR libraries that fulfill the service of construction of Payment Status reports related to received SEPA Credit Transfer messages.

National format to SDD mapping on page 9

CFONB to SCT mapping on page 25

DTAUS0 to SCT mapping on page 30

SCT to PSR mapping on page 33

PSR generation (SCT/SDD to PSR mapping: FF01 control) on page 46


National format to SDD mappingAbout SDD management in Financial Standards Library 9Transformation to SDD 10Operating modes 12Financial Integration mandate repository 15Configure B2Bi for national format to SDD 19Test SDD with sample data 22

About SDD management in Financial Standards LibraryThe SEPA Direct Debit Management libraries enable the transformation from a national payment format to the SEPA Direct Debit (SDD) format, which is the SEPA flavor of the ISO20022 pain.008.01.x format. The SDD mapping libraries provided with Axway Financial Standards Library use the French national payment format, called either CFONB or AFB format, as the source of the SDD transformation, as well as the German DTA formats. The transformation library is provided in such a way that its first stage, dedicated to the transformation of the national format to an intermediate SDD format, can be easily used as a sample to provide a new transformation from another national format.

The SDD format produced by this transformation complies with the "SDD scheme rule book" and the "SDD implementation guide" published by the European Payments Council (EPC). In particular, the "SDD Management" libraries implement these two specific features:

l Mandate data embedded within the pain.008.001.x: The SDD format embeds data structure related to the mandate authorizing the debit, including the Unique Mandate Reference (UMR) and SEPA Creditor ID (ICS - Indentifiant Créancier SEPA). This kind of data is not contained in the national format so the SDD Management libraries provide the following features:

o A library providing a way to acquire data from any mandate application, to store and to update the mandate data that is required within the SDD. This mandate data is stored in a dedicated database enabling an enrichment of the SDD at runtime, compatible with the high level of performance required by the use case (an SDD could contain more than one million payment orders). See Financial Integration mandate repository on page 15 for more information.

o A service called by the second stage of the transformation that retrieves the mandate data related to the payment orders contained within the SDD and enriches them with the mandate data stored in the Financial Integration mandate repository.

o A service that updates the Mandate data to enable the management of the Sequence type and issue update information for the Master mandate application to help it to manage the mandate life-cycle.


2 SEPAmappings

l SDD sorted against the Debit order sequence type: The pain.008.001 is a multi-remittance message. A remittance must group Payment orders with same Creditor, same Collection date and same Sequence type. The sequence type is the position of the order:

o FRST: First payment of a sequence

o RCUR: Recurrent payment in a sequence (not the first, not the last)

o FNAL: Final payment of a series

o OOFF: One-shot payment

When a transaction is in "Amended State" (when there is a change in the debtor’s BIC+IBAN in the transaction of an SDD message) then the transaction should be part of the payment information marked with Sequence Type<SqTp> as "FRST", and Original Debtor Agent<OrgnlDbtrAgt> marked as "SMNDA" along with Amendment Indicator as "true".

If there is another transaction which does not use its mandate for the first time, then it should belong to payment info marked with Sequence Type as "RCUR".

Note that the "FRST" and "RCUR" transactions are not processed at the same time, as the "FRST" transactions have to be sent to the recipient bank 6 days before execution date (2 days required for "RCUR" transactions).

Besides the transformation from national formats to SDD, the SDD management libraries provide a mandate migration service. This service enables the creation of SEPA mandates from individual national payment orders. When in migration mode, the relevant fields from each national format payment record are extracted and reassembled into a new mandate record. This automated mandate creation is only possible in countries that authorize this type of migration (such as France). The migration process is executed according to the French rules and may have to be adapted to the rules implemented in other countries.

The SDD Management libraries make full use of the validation and conversion functions delivered with the Reference Data libraries installed as part of Financial Standards Library.

Transformation to SDDThe overall transformation service consists of three distinct stages. Each stage is briefly described, along with more detailed information in the individual operating mode sections.

Stage 1: Generation of an intermediate SDD document (including the UMR)This stage enables:

l The transformation of a national format (French CFONB format delivered as sample) into an intermediate SDD document. This transformation is handled by a component that can be customized to support other national payment formats.

l The retrieval (or creation) of the Unique Mandate Reference (UMR) and SEPA Creditor ID (ICS - Indentifiant Créancier SEPA) will, depending upon the practices of the customer, vary between being very easy and quite complex.


2 SEPAmappings

In simple use cases the UMR can be transmitted as it exists within the national source format or it may require some extra processing because it is not directly extractable from the national source format. The component computing the UMR in the delivered libraries provides a simple extraction of the UMR from the debtor reference ID fields of the CFONB and DTAUS0 message. This component can be customized to be adapted to the practices of each individual customer.

The ICS mapping must be customized because the provided default only works with generated test data and is not SEPA compliant.

Stage 2: Generation of the final SDD - enrichment with the mandate dataThis stage enriches the intermediate SDD with the mandate data available in the Financial Integration mandate repository. As each direct debit transaction is processed, its corresponding mandate record is updated and written to the Mandate output file, to be sent later to the Master mandate application to help it to manage the mandate life-cycle.

Stage 3: Output validation and final processingThis stage performs the final validation and constraint checking of the output documents. Any other custom finalization functions can also be performed at this time.


2 SEPAmappings

Operating modes

Production modeThe following diagram provides a view of national format to SDD mapping operation in production mode. Production mode takes national files (for example CFONB or DTAUS) as input and provides an SDD mandate-update and processing result file as output. A step-by-step description is provided after the diagram.

First mapping stageThe first mapping stage converts a national file format into a partially filled SDD usable by the second mapping stage to complete the SDD document.

The national file is processed by Integrator.

As the national file is mapped, the following occurs:

l The account numbers and so on are converted to IBAN using the Financial Integration reference database


2 SEPAmappings

l The Unique Mandate Reference and Creditor Id are obtained from the national file data

l The content of the national file is mapped to the intermediate SDD file

Note that the second mapping stage expects a Unique Mandate Reference to be available for each direct debit. If the latter is missing then the SDD file will be treated as an error.

Second mapping stageThe second mapping stage performs the mapping from the intermediate SDD to the final valid SDD with mandate information.

l The intermediate SDD from the first mapping stage is loaded by the JMC.

l For each direct debit in the input SDD, the JMC looks up the mandate in the database using the Unique Mandate Reference (UMR) and ICS.

l If there is no mandate associated with the UMR and ICS, then that individual direct debit is rejected and is treated as an error.

l If there is a mandate associated with the UMR and ICS but a mismatch exists inside the financial references (Creditor Name, Debtor Name, Creditor BIC and Debtor IBAN) in the input and mandate data, then a WARNING is generated. The result is processed but the output SDD is generated with financial references the same as mandate database data. The mismatch in financial references is considered as a warning and not an error.

l One SDD file is created for all valid direct debits together with a mandate file that describes the changes to the mandates triggered by this mapping.

l For any rejected direct debits, the output SDD will not be created but there will be a mandate with the relevant data and processing result stating the reason for rejection.

Third mapping stage l This phase allows the content of the SDD produced in the second stage to be validated based on customer requirements.

l The SDD is checked and validated against the rules defined in the SEPA SDD Implementation Guide.

l Either the SDD is invalid and it is rejected or it is valid and the SDD is made available for delivery.


2 SEPAmappings

Migration modeThis mode is about using the national file data to create stub mandate files that can be later modified by customers. The following diagram provides a view of national format to SDD Mapping operation in migration mode. Migration mode takes national files (for example CFONB or DTAUS) as input and provides a mandate file and processing results file as output. A step-by-step description is provided after the diagram.

First mapping stageThe first mapping stage is the same as the one in production mode (see First mapping stage on page 12).

Second mapping stage l The intermediate SDD is loaded by the JMC.

l For each direct debit in the input SDD, the JMC looks up the mandate database using the Unique Mandate Reference (UMR) and ICS.

l If a mandate already exists, it is added to the processing result file for informational purposes.


2 SEPAmappings

l If there is no mandate then it is added to the mandate-data file as a new mandate record in MIGRATING state.

Third mapping stageThe MIGRATION mode mandate records created by this process are not ready for production use. They must first be completed with any missing data that was not available in the national format file (for example, the Date of Signature).

For more information see Migration flow (Migration) on page 19.

Financial Integration mandate repositoryThe Financial Integration mandate repository is the core of the national format to SDD mapping process. It is responsible for providing transaction time copies of all mandates needed during the data transformation and aggregation phase (stage 2).

The repository is managed via the Financial Integration Data Management layer using a custom XML data format.

Overview of the APIThis section provides a brief overview of the API.

XML example

<FexMandateInformation>

<ProcessingOptions>

<TruncateTables>true</TruncateTables>

</ProcessingOptions>

<Create>

<Mndt>

<Id>

<Umr>PR1104110001</Umr>

<CdtrId>FR69ZZZ0123456789</CdtrId>

</Id>

<MndtState>ACTIVE</MndtState>

<SeqTp>FRST</SeqTp>

<Cdtr>

<Nm>CAISSE PRIMAIRE ASSURANC</Nm>

</Cdtr>

<DtOfSgntr>2012-11-14Z</DtOfSgntr>

<Dbtr>


2 SEPAmappings

<Nm>ABDELMALEK BRAHIM</Nm>

<Iban>FR1720041010111150028P03215</Iban>

<AgntBic>PSSTFRPPNTE</AgntBic>

</Dbtr>

</Mndt> <Mndt>...</Mndt>

<Mndt>...</Mndt>

...

</Create>

<Update>

<Mndt>...</Mndt>

<Mndt>...</Mndt>

...

</Update>

<Remove>

<Mndt>...</Mndt>

<Mndt>...</Mndt>

<Mndt>...</Mndt>

...

</Remove>

</FexMandateInformation>

Key sections

Section Description

<ProcessingOptions> Contains optional settings to apply when processing this set of mandate information.

<TruncateTables> This indicates whether or not the mandate repository database tables should be truncated (erased) before applying the current information. Note: This only applies to <Create> mode updates.Possible values: true, falseDefault value: false

<Create> Creates new Mandate objects in the repository.Each <Mndt> block in this section must contain at a minimum the required fields. The <Id> block contains the mandate ID (UMR/RUM) and SEPA Creditor ID (SCI/URM). These two fields combine to represent the key to the mandate, and the combination must be unique across the entire mandate repository.


2 SEPAmappings

Section Description

<Update> Update existing Mandate objects in the repository.Each <Mndt> block in this section must contain at a minimum the required fields, and have an <Id> that matches an existing mandate record. Any fields missing from this section but existing in the repository will be removed from the repository record.

<Remove> Each <Mndt> block in this section must contain at a minimum the required fields, and have an <Id> that matches an existing mandate record. Any fields missing from this section but existing in the repository will be removed from the repository record

Financial Integration specific fieldsThe majority of the fields available in the <Mndt> block conform one-to-one with the SDD specification. However there are some Financial Integration specific fields available that allow greater control and tracking of individual mandate records.

Section Description

<MndtState> Indicates the current state of a mandate record.Possible values:

l ACTIVE – The mandate is complete and available for processing

l AMENDED – The mandate has had amendment data added to it which requires the amendment rules to be applied during the next SDD processing

l MIGRATING – The mandate is in the process of being migrated and is not available to be used to create SDD data

l DISABLED – The mandate is not available to be used for SDD processing

<PrevColltnDt> The date of the last collection made against this mandate.

<PrevColltnAmt> The amount of the last collection made against this mandate.

<ColltnCount> The total number of collections made against this mandate.


2 SEPAmappings

Repository data maintenanceThere are multiple ways of creating and maintaining Mandate data within the repository. Depending on the customer needs and environment, one or more of these methods may be used. The following diagram shows the three most common use cases (two for production, one for migration), and what follows is a brief overview of the differences between them.

Common data management (shared)All three of the example flows share these common components that are used for performing the desired data operations against the repository.

1. FexMandateInformation XML is provided to the FEX Data Access JMC.

2. The JMC triggers the database update performing the requested Create, Update, or Remove operations.

3. The results of the operation are sent to the Processing results output channel.


2 SEPAmappings

Direct mandate update (Production)This is the simplest use case which provides timely database updates at the expense of not keeping the Master mandate application in sync.

1. FexMandateInformation XML produced by the Direct Debit Handler JMC is sent directly to the common data management components.

Update via external mandate manager (Production)This is a more complex use case involving multiple external tools/processes.

1. FexMandateInformation XML produced by the Direct Debit Handler JMC is sent to a custom process that provides the data to the Master mandate application.

2. The data is merged back into the master mandate repository.

3. A delta or complete set of mandates is sent to the common data access components where it is applied to the Financial Integration mandate repository.

Migration flow (Migration) 1. FexMandateInformation XML in MIGRATING state is produced by the Direct Debit Handler JMC

running in migration mode.

2. This data is passed to a custom process that fills in any missing fields that were not available from the national format during migration.

3. The completed mandate data is passed to the common data access components where it is applied to the Financial Integration mandate repository.

Configure B2Bi for national format to SDD

Integration-ProcessesThere are three Integration-Processes delivered along with the map project that must be configured in B2Bi in order to perform SDD processing:

l IP_CfonbToSdd

l IP_DtausToSdd

l IP_MandateDataManagement

IP_CfonbToSdd 1. Launch the Mapping Services/B2Bi Client.

2. Import the map project (SDD_Managment) into the workspace.


2 SEPAmappings

3. Deploy All Flows from SDD_Mangement\FEX\Example\CFONB_TO_SDD onto the runtime server.

4. Register FEX Mapping SEPA Direct Debit Handler JMC. For details, see Register JMC on B2Bi on page 124.

5. Import the CIP (CIP_SDD_Management) in B2Bi Integration Services (Open Windows Start > B2Bi Client > B2Bi Tools > B2Bi Integration Services) and check if SDD_Management\Integrations\FEX\Example\CFONB_TO_SDD exists or not:

a. If yes, deploy the ip_cfonbtosdd onto the B2Bi Server. (Go to Configuration Browser, right-click SDD_Management and select Deploy). Create a connection in Runtime Server Browser if a connection is not made.

b. If an error occurred, check your installation.

6. Create an Application Pickup of type Application FTP (providing a directory location for the file pickup).

7. Add the deployed ip_cfonbtosdd (CIP) as a component of MAP type in B2Bi.

8. Create a Service of type Metadata, add the above component in service and select Application Delivery.

9. Create a Metadata Profile:

a. Add the service created earlier.

b. In Criteria, select the following as per input file name if, for example, input test file: bevent.in:

Metadata Condition Value

Integration Engine: FTP RemoteFileName

equals bevent.in

This metadata rule is just an example. Any criteria can be selected.

10. Test this configuration with input files.

IP_DtausToSdd 1. Launch the Mapping Services/B2Bi Client.


3. Deploy All Flows from SDD_Mangement\FEX\Example\DTAUS_TO_SDD onto the B2Bi Server.

4. Register DTAUS Transformation JMC and FEX Mapping SEPA Direct Debit Handler JMC. For details, see Register JMC on B2Bi on page 124.

5. Import the CIP (CIP_SDD_Management) in B2Bi Integration Services (Open Windows Start > B2Bi Client > B2Bi Tools > B2Bi Integration Services) and check if SDD_Management\Integrations\FEX\Example\DTAUS_TO_SDD exists or not:


2 SEPAmappings

a. If yes, deploy the ip_dtaustosdd onto the B2Bi Server. (Go to Configuration Browser, right-click SDD_Management and select Deploy). Create a connection in Runtime Server Browser if a connection is not made.

b. If an error occurred, then check your installation.

6. Create an Application Pickup of type Application FTP (providing a directory location for the file pickup).

7. Add the deployed ip_dtaustosdd (CIP) as a component of MAP type in B2Bi.

8. Create a Service of type Metadata and add the above component in service and select Application Delivery.






equals bevent.in


10. Test this configuration with input files.

IP_MandateDataManagement 1. Launch the Mapping Services/B2Bi Client.


3. Deploy All Flows from SDD_Mangement\FEX\Example\Mandate onto the B2Bi Server.

4. Register FEX Mapping Data Management JMC. For details, see Register JMC on B2Bi on page 124.

5. Import the CIP (CIP_SDD_Management) in B2Bi Integration Services (Open Windows Start > B2Bi Client > B2Bi Tools > B2Bi Integration Services) and check if SDD_Management\Integrations\FEX\Example\Mandate exists or not:

a. If yes, deploy the ip_mandatedatamanagement onto the B2Bi Server. (Go to Configuration Browser, right-click SDD_Management and select Deploy). Create a connection in Runtime Server Browser if a connection is not made

b. If an error occurred, check your installation.

6. Create an Application Pickup of type Application FTP (providing a directory location for file pickup).

7. Add the deployed ip_mandatedatamanagement (CIP) as a component of MAP type in B2Bi.

8. Create a Service of type Metadata and add the above component in service and select the Application Delivery.


2 SEPAmappings



b. In Criteria, select the following as per Mandate file name, for example, input test file: Mandates.xml:



equals Mandates.xml


10. Update the Mandate Data Repository with this configuration using the mandate input files for respective formats.

Test SDD with sample dataAfter the sample flows have been configured, you can test them using the provided data samples.

Note If testing sample data terminated with Windows end-of-line characters (carriage return line feed), you might, depending on Integrator version, need to edit the CFONB_160_PLVT_V2 business document and change all delimiter strings from '0x0A' to '0x0D 0x0A'.

To ensure that the correct data is available for each step, these examples must be followed in the order described here.

Load BIC/IBAN dataFor details about updating the BIC/IBAN data repository, see Importing and updating reference data on page 94.

Generate migration mandates 1. Go to the <Axway_installation_root>/Financial_Standards_

Library/conf/jmc directory.

2. In the DirectDebitHandlerDefault.properties file, set the runMode property to MANDATE_CREATION.

3. Go to the <Axway_installation_root>/Documentation/resources/sample-data directory.

4. Use the 5_recipients_in_2_remittances.cfonb file as input file.

If mandate data is needed for DTAUS format, then a DTAUS file must be used.


2 SEPAmappings

5. Validate the two outputs:

l A file consisting of five mandate records in MIGRATING state

l A file with the following in the summary section:

<NumberDirectDebitsProcessed>5</NumberDirectDebitsProcess

ed>

<NumberMandatesCreated>5</NumberMandatesCreated>

In the case of DTAUS, the number of direct debits processed will depend upon the payment orders in the input file.

Load mandates into the repositoryThe mandate output file generated in the previous step does not contain active mandate data. This step uses a mandate source file that simulates what the previous data would look like after being completed by the external master mandate process.


2. Use the create_5_mandates.xml file as input.

In the case of DTAUS, use the DTAUS mandate file generated in the previous section as input.

3. Validate the output:

l A file, with the following in the summary section:

<NumberRecordsProcessed>5</NumberRecordsProcessed>

<NumberRecordsCreated>5</NumberRecordsCreated>

In the case of DTAUS, the number of records processed will depend upon the DTAUS mandate file generated in the previous section.

Create SDD data from CFONB 1. Go to the <Axway_installation_root>/Financial_Standards_


2. In the DirectDebitHandlerDefault.properties file, set the runMode property to SDD_CREATION.


4. Use the 5_recipients_in_2_remittances.cfonb file as input.

5. Validate the three outputs:

l A file containing the direct debit payments

l A file containing the mandate records

l A file containing the summary of records processed, rejected or warned about


2 SEPAmappings

Create SDD data from DTAUS 1. Go to the <Axway_installation_root>/Financial_Standards_


2. In the DirectDebitHandlerDefault.properties file, set the runMode property to SDD_CREATION.

3. Provide a DTAUS file as input.

4. Validate the three outputs:

l A file containing the direct debit payments

l A file containing the mandate records

l A file containing the summary of records processed, rejected or warned about

Update the mandate repository 1. Take the active mandate file (that you generated earlier) as input file.

2. Validate the output:

l A file with the following in the summary section:

<NumberRecordsProcessed>5</NumberRecordsProcessed>


<NumberRecordsUpdated>5</NumberRecordsUpdated>


2 SEPAmappings

CFONB to SCT mappingAbout CFONB to SCT mapping 25CFONB flows 25Configure B2Bi for CFONB to SCT 29Test flows with sample data 29

About CFONB to SCT mappingThe SCT mapping libraries enable the transformation of national payment formats to the SEPA Credit Transfer (SCT) format. These libraries also support the SEPA migration use case for corporate customers.

An example of a national format is CFONB (Comité Français d'Organisation et de Normalisation Bancaires) for France. The samples supplied with Financial Standards Library relate to the CFONB standard.

CFONB flowsThe Financial Integration flows listed in the following table transform CFONB messages into SEPA messages.

Flow name CFONB input format

SEPA output format Handling constraints

CFONB_160_VIRT_to_SEPACustBnkCrdtTrsfr

CFONB (160_VIRT)

Customer to BankCredit Transfer(pain.001.001.03)

None

CFONB_320_VETR_to_SEPACustBnkCrdtTrsfr

CFONB (320_VETR)

Customer to BankCredit Transfer(pain.001.001.03)

See CFONB (320_VETR) input information and constraints on page 27


2 SEPAmappings

Message handling information and constraints

General considerations

Error handling

During message handling in Integrator the rejection of a file could be global or partial. For example, with a file containing multiple remittances, each remittance containing multiple operations:

l In partial reject mode, only the correct remittances are transformed to SEPA format. The remittances in error (because of an incorrect header or footer, or because of an incorrect operation) are not transformed to SEPA.

l In global reject mode, if one or more remittances are in error, all remittances (including the correct remittances) are rejected in error.

Transformation mapping functions

l Initiating party identification: <GrpHdr><InitgPty><Nm>xxxxxxx</Nm></InitgPty></GrpHdr>.

This information can be initialized using a configuration variable.

l Message ID to be supplied by the map conversion: <MsgId>xxxxxxx</MsgId>.

It is suggested that you use an ID syntax such as "FEXloggerId/FEXHostName/TCPCommandPort". The number of characters must be less than or equal to 35.

l Payment information ID to be supplied by the map conversion if not present in the CFONB input file: <PmtInf><PmtInfId>xxxxxxx</PmtInfId></PmtInf>.

It is suggested that you use an ID syntax such as "XIBloggerId/Remittancenumber/XIBHostName/TCPCommandPort". The number of characters must be less than or equal to 35.

l Set the Category Purpose field (<PmtInf><CtgyPurp>xxxxxx</CtgyPurp></PmtInf> and <PmtInf><CdtTrfTxInf><Purp><CD>xxxxxx</CD></Purp></CdtTrfTxInf

></PmtInf>), based on fields from the input file. For the moment, there are no rules which clearly define how to set this field (the values depends on input file properties).


2 SEPAmappings

CFONB (320_VETR) input information and constraints

Currency

All payment transactions must use the Euro currency.

l If field 03/19 = 1 or 3, then field 03/16 must be "EUR"

l If field 03/19 = 2 or 4 then ALL 04/25 fields must be "EUR"

Creditor account

The creditor account value is not mandatory. However, for CFONB to SEPA mapping, the creditor account field (04/5) has to be set in each payment transaction of an 320_VETR remittance. If not, the remittance must be rejected.

IBAN processing

l For the debtor account field (03/11), IBAN and RIB are authorized (the 03/10 field gives information on the 03/11 field format: "1"=IBAN, "2"=RIB). Converting RIB to IBAN consists of adding "FR" plus the IBAN key.

l For the creditor account field (04/5), BBAN national identifier and IBAN are allowed:

o If (04/4 = "1") then 04/5 is in IBAN format

o If (04/4 = "2") then 04/5 is in BBAN format

o If (04/4 = "0") then the remittance must be rejected

l If the BBAN is provided:

o If 05/06 (BIC CODE) is present, it includes the country code. To convert the BBAN account number into IBAN, add the country code plus the IBAN key at the beginning of the BBAN.

o If 05/6 is not present, then field 05/7 (beneficiary bank country code) is mandatory. To convert from the BBAN account number to IBAN, add the country code plus the IBAN key at the beginning of the BBAN.

Adding a BIC

l For the debtor account, either:

o The BIC code may be available in the 03/09 field

o If the 03/09 field does not contain a value, the BIC is deduced from the IBAN account debtor

l For the creditor account

o The BIC code may be available in the 05/06 field

o If the 05/06 field does not contain a value, the BIC is deduced from the IBAN account creditor


2 SEPAmappings

Chargebearer account

For the chargebearer account fields (04/20, 04/21 and 04/22), the present release of the SEPA Map-Broker does not map the fields to pain001. If fields 04/20, 04/21 and 04/22 are present in the 320_VETR input file, they must be ignored.

Execution date handling

For the execution date for payment transactions, in 320_VETR, the execution date is provided at the payment transaction level, whereas in SEPA the execution date is provided at the remittance level. For Map-Broker handling, if the 320_VETR remittance is in multi-date format, the 320_VETR remittance will be split into multiple SEPA remittances.

For the execution date for payment transactions, in 160_VETR, the execution date is provided at the payment transaction level, whereas in SEPA the execution date is provided at the remittance level.

In CFONB, the date is in the format DDMMY whereas the SEPA date is in the format CCYYMMDD.

It is formulated so that the date given within the CFONB file is never more than one year in the past from the current processing date as shown in the examples below:

Processing in 2014, 3 (in CFONB) means 2013 (in SEPA)

Processing in 2014, 4 means 2014


...






...




So for processing in 2020, 1 means 2021

...



2 SEPAmappings

Important:

l The map project delivered with Financial Standards Library 3.9.0 for CFONB to SCT mapping uses the new BIC referential delivered with Financial Standards Library 3.9.0.

l To use the new BIC referential or new Custom-Functions you need to configure Financial Standards Library 3.9.0 on B2Bi.

Configure B2Bi for CFONB to SCT 1. Launch the Mapping Services/B2Bi Client.

2. Import the map project (CFONB_SCT_2014) into the workspace.

3. Deploy the Flow (for example, 1CFONB_160_VIRT_to_1SEPACstmrtoBnkCdtTrfInfV70.dmlflw) onto the B2Bi Server.

4. Add the flow (for example, 1CFONB_160_VIRT_to_1SEPACstmrtoBnkCdtTrfInfV70.dmlflw) as a component of MAP type.

5. Add B2Bi Inhouse File Detection V1 as a component of type Detector. In the Configuration tab set the following attributes in quotes ("attribute_name"):

a. Sender Id: "SID"

b. Receiver Id: "RID"

c. Document standard: "INHOUSE"

d. Document type: "ORDER"

e. Number of characters to read in file: 10000

f. Debug: Y.

g. Save the changes.

6. Create a document service of type Inhouse and add the above deployed flow as a map in it.

7. Create a messaging id of type Inhouse for partner and virtual partner.

8. Create an Inhouse agreement and include the above-mentioned document service in it.

9. Test this configuration with an input file.

10. Configure any other CFONB_SCT flows in the same manner.

Test flows with sample dataAfter the sample flows have been configured, you can test them using the provided data samples.



2 SEPAmappings

DTAUS0 to SCT mappingAbout DTAUS0 to SCT mapping 30Configure B2Bi for DTAUS0 to SCT 31Test flows with sample data 32

About DTAUS0 to SCT mappingThe SCT mapping libraries enable the transformation of national payment formats to the SEPA Credit Transfer (SCT) format.

An example of a national format is DTAUS0 (DatenTrägerAustausch) for Germany.

Functional flow

Functional terminology l DTAUS: Permits electronic processing of payment orders (credit transfers and direct debits) in the German domestic payments.

l SEPA: Single Euro Payments Area

l To attain this goal, SEPA relies on the ISO 2022 standards and specifies some formats regarding European options and specific features.

l Payment: A payment is an order to transfer an amount of money from one account to another. The owner of the account is usually a corporate. The Payment Order may contain several transfers, towards/from several targeted accounts. The Payment Order may be either:

o Credit Transfer: The money goes from the corporate to the recipient, for instance an employee (salary) or a supplier (bill).

o Debit Transfer: The money comes from one of the corporate customers, for instance to pay a scheduled bill, using a mandate.


2 SEPAmappings

l DTAUS JMC (DTAUS Transformation JMC): This JMC component transforms the input to make it Axway DTAUS compliant by adding an Axway header and separators, which can be further used by the next map (DTAUS0_SCT Map).

l Map (DTAUS0_To_SEPACstmrtoBnkCdtTrfInfV60): Enables the transformation of DTAUS to SCT format. In the map, required fields are mapped and validation of each format is performed, which includes checking of:

o Structure compliance

o Validation rules applied on each format.

o Required transformations

Important:

l The map project delivered with Financial Standards Library 3.9.0 for DTAUS0 to SCT mapping uses the new BIC referential delivered with Financial Standards Library 3.9.0.

l To use the new BIC referential or new Custom-Functions, you need to configure Financial Standards Library 3.9.0 manually on B2Bi.

Configure B2Bi for DTAUS0 to SCT 1. Launch the Mapping Services/B2Bi Client.

2. Import the map project (DATUS0_SCT_2012) into the workspace.

3. Deploy the flow (DTAUS0_To_SEPACstmrtoBnkCdtTrfInfV60) onto the B2Bi Server.

4. Add the following component in B2Bi:

a. B2Bi Copy Message as MAP Type.

b. DTAUS Transformation JMC as Document Type.

c. DTAUS0_To_SEPACstmrtoBnkCdtTrfInfV60 flow as Document Type.


a. Sender Id: "SID"



d. Document type: "ORDERS"


f. Debug: Y


6. Create a document service of type Inhouse and add COPY JMC as a map in it.

a. In the additional components add DTAUS JMC in it.

b. Add DTAUS_SEPA document as the additional component.

7. Create messaging id of type Inhouse for partner and virtual partner.


2 SEPAmappings

8. Create an Inhouse agreement and add the service that you created.





2 SEPAmappings

SCT to PSR mappingAbout SCT to PSR mapping 33Functional terminology 34SCT-PSR mapping method 36PSR versions 37Configure SCT to PSR maps 39Configure B2Bi for SCT to PSR 41Functional implementation 42Compute Payment Status 44Technical objects 45

About SCT to PSR mappingThe SCT to PSR mapping libraries enable you to record all errors (ISO Controls) in the Payment Status Report (PSR) and to compute the global status of Payment.

For information about ISO controls, see Technical objects on page 45.

Structure of the input data: SCTSCT comprises three parts:

Element Cardinality Contents

Group Header

Mandatory, Unique

l Identification of the Order (Id, date)

l Identification of the Corporate (Name, Address, BIC/BEI/CHIPS/DUNS, and so on)

l Control sum of the amount of the whole OrderTotal number of Transactions

Payment Group

Mandatory, Multiple

l Debtor information

l Debtor agent

l Debtor account

Transaction Mandatory, Multiple

l Amount, Currency

l Value Date

l 3 Intermediary accounts

Each Transaction is described and belongs to one Payment Group.


2 SEPAmappings

Structure of the output data: PSRPSR comprises three parts:

Element Cardinality Contents after mapping

Group Header Mandatory, Unique Identity of the Corporate issuing the Payment Order

Group Status Mandatory, Multiple

The global status of the PaymentFor each Status (RJCT, PART) and ISO Error Code:

l The number of the Transaction involved

l The sum of the amount detected in error

Transaction Status

Mandatory, Multiple

For each Transaction in error:

l The identification code of the Transaction

l The ISO Code of the error

l The explanation of the error in plain text

Functional terminology l ISO 2022

This worldwide standard aims to define the format of electronic exchanges that are related to financial transactions between two Banks or between a Bank and its corporate customers.

l SEPA: Single Euro Payments Area

To attain this goal, SEPA relies on the ISO 2022 standards and specifies some formats regarding European options and specific features.

l Payment

A Payment is an Order to transfer an amount of money from one account to another one. The owner of the account is usually a Corporate. The Payment Order may contain several transfers, towards/from several targeted accounts.

The Payment Order may be either:

o Credit Transfer: the money goes from the Corporate to the Recipient, for instance an employee (salary) or a supplier (bill).

o Debit Transfer: the money comes from one of the Corporate Customers, for instance to pay a scheduled bill, using a Mandate.

l PSR (Payment Status Report)


2 SEPAmappings

When the Payment Order is sent to the Bank, the Bank processes it, and, depending on the contract between the Corporate and the Bank, the Bank issues none or several Payment Reports, stating the acceptance for each Payment. This process involves Bank to Bank feedback depending on the Report Level.

l Report Level

A report may be sent at different levels:

o Technical Level: The Payment Order is successfully transmitted to the Bank, meaning that the Bank acknowledged that the transport authentication credentials were accepted. Alternatively, the transfer failed this step.

o Application Level: The Bank acknowledges the content of the files. For example:

o The XML document conforms to the XML syntax.

o All account numbers are correct, exist and are consistent with the given name and address.

o The Dates given inside the data are consistent with the process involved.

o The value of the amount is filled in.

o Post Operation LevelTransaction Report Level: The Bank provides the feedback for the action taken about the Payment Order.


2 SEPAmappings

SCT-PSR mapping methodThe following sample diagram shows a simplified view of the mapping structure:

In the Payment Status Report, all erroneous transactions are copied to the Transaction Status group, along with their error code and error message set.

In addition to this Transaction Status group, statistical data is collected inside the Payment Status group. This PaymentStatus group contains the number of erroneous transactions with the cumulative amount of all transactions in error.

Note that there is a REJECTED status inside the Payment Status block, but also an RJCT status inside the Transaction Status block.


2 SEPAmappings

PSR versionsThe following diagrams show the mapping differences between PSR versions 2 and 3.

PSR version 2


2 SEPAmappings

PSR version 3


2 SEPAmappings

Configure SCT to PSR maps

PrerequisitesCheck these prerequisites before you configure maps on B2Bi.

Create/validate the database schema l Create a database by importing the schema SCT_PSR_schema.xml located in <Axway_

installation_root>/Financial_Standards_Library/conf/db/schema into the database that is configured for using custom functions.

l After configuring the database, two tables "Features" and "MsgIdTable" should be created in the database.

l Insert different attribute values inside the "Features" table. See Configure map features on page 39.

Import s4h attribute fileThe SCT_PSR_Attributes_Setting.s4h file contains the list of all attributes to be used in the flow. This file is located in <Axway_installation_root>/Financial_Standards_Library/Integration/s4h.

Copy the SCT_PSR_Attributes_Setting.s4h file to:

l %CORE_LOCAL%\config\attribute

l %CORE_ROOT%\4edi\include

Update BIC/IBAN data repositoryFor details about updating the BIC/IBAN data repository, see Importing and updating reference data on page 94.

Configure map featuresSeveral features are provided with the IP. You can enable or disable these features according to your requirements.

List of map features

l GenerateCorrectOutput - Y/N

The Input message is transferred to output. If set to N, only the PSR file is generated, the input message is not transferred.

l PreventOutputOnError - Y/N


2 SEPAmappings

Forbids the forwarding of the input message to the output when any error has been detected. Therefore, transferred messages are always fully valid. In the case of an error, the customer must resend the full message.

l SendPSRCorrectTransaction - Y/N

If set to "Y", the PSR message contains all transactions, being in error or not. Therefore the PSR message also contains ACCEPTED transactions. The PSR process generates the PSR to detect anomalies, but does not remove "correct" transactions.

If set to "N", only error transactions are transferred inside the PSR message. Whatever the settings, this behavior does not change the Number of Transactions per Status.

l Enable_XXXX - Y/N

o XXXX represents any ISO standard error code. If set, this option enables the associated control.

o Enable_AC01" stands for the CheckDigit of IBAN codes

o Enable_AM05" stands for the File Identifier uniqueness

o Enable_BE04" stands for the Missing Creditor Address

o Enable_RC01" stands for the BIC exists inside the FEX

o Enable_RR01" stands for the Missing Debitor Account or Identification

o Enable_RR02" stands for the Missing Debitor name or Address

o Enable_RR03" stands for the Missing Creditor name or Address

o Enable_AM10" stands for the ControlSum check

l Language – FR/EN

Choose between French or English error messages written inside the generated PSR.

l PSR_BIC_CODE

Current BIC code that identifies the Bank generating the PSR. This value is mandatory to be able to do the mapping. If not set, the input message is rejected.

Most of the above-mentioned features must be set to "Y" or "N", depending on requirements, where:

l Y = Enabled

l N = Disabled

Exceptions to this are: PSR_BIC_CODE and Language.

How to configure the map features

As each feature is related to a specific attribute, here is where you must change the attribute value.

Configure the following maps as required:

l FeaturesSeting Map

l SendPSRCorrectTransaction Map

l Error Map


2 SEPAmappings

Configure B2Bi for SCT to PSR 1. Launch the Mapping Services/B2Bi Client.

2. Import the map project into the workspace:

l SCT_PSR_V2.zip for PSR Version 2, or

l SCT_PSR_V3.zip for PSR Version 3

3. Deploy the flow onto the B2Bi Server:

l SCT_PSR_V2.flw for PSR Version 2, or

l SCT_PSR_V3.flw for PSR Version 3

4. Create a JDBC channel inside the connection, providing a link to the database where the schema (SCT_PSR_schema.xml) is imported. See Create/validate the database schema on page 39.

5. Add the deployed flow as a component of MAP type.

6. In the Input tab, inside the component, select "Defined as per output" option in "Action when no output created by flow".

7. In the all outputs tab, select "Ignore" for "Action when no output is created".

8. Create a document service of type XML and add the above deployed flow as a map in it.






equals bevent.in


10. Test this configuration with an SCT input file.


2 SEPAmappings

Functional implementation

General architectureThis implementation provides the computation of the Payment Status Report on the Bank side, for the Level "Format" and "Data Consistency".

The implementation relies on the SEPA standards. It checks a list of ISO-defined controls (see Technical objects on page 45 for a list of the ISO controls).

Mandatory parametersTo process the Input, the mapping requires some mandatory information:

Language choice

The Mapping generates the explanation of the detected anomaly in French and English. You may also easily add a new language by filling in a DML Table.

Bank Identifier

The Status Report requires the use of the BIC of the Bank that generates the Status Report. This information must be completed in the Parameters of the Mapping.

Optional features

Send "Positive" AcknowledgementDepending on the contract between the Bank and a Corporate, there may be an implicit acknowledgement for each received Payment: the bank only sends Payment Status if errors are detected. This behavior is the norm in France. Other countries may generate the Positive acknowledgement behavior. When the Positive Acknowledgement is chosen, the Mapping generates a Status Report with the Accepted status when no errors are found.

Choose controls to applyDepending upon processes (previous or future) implemented in each Bank, some controls may already be implemented. The Mapping allows you to independently implement or disable specific controls. For more information, see "Enable_XXXX" in Configure map features on page 39.


2 SEPAmappings

Transfer input file to OutputThe Mapping may transfer the output file to a dedicated Channel.

The transfer may be subject to error detection to avoid transferring the Input file if any errors have been found.

Therefore, one of two sets of conditions must be checked in order to get the SCT as an Output:

l The option GENERATECORRECTOUTPUT has been set to "Y".

l The option PREVENTOUTPUTONERROR has been set to "N".

OR

l The option GENERATECORRECTOUTPUT has been set to "Y".

l The option PREVENTOUTPUTONERROR has been set to "Y".

l No errors are detected in the SCT file.

Implement optional featuresAll these features may be enabled or disabled dynamically for each individual SCT. This is done by setting a value in the corresponding Integrator Attribute before the Mapping itself.

Note You can alter the behavior so that some Attributes are uniform for all incoming flows. Use DML to set a static value for the targeted Attribute.


2 SEPAmappings

Compute Payment StatusTo compute the Status on the Payment Status group, two types of information are used:

l The accuracy of all controls applied to the Transactions

l The accuracy of all controls applied to the Payment Group

Status formula

If Controls on Payment Group are

If number of Rejected Transaction of this Payment Group is

Then Payment Group Status is

In Error <Any value> REJCT

Valid 0 ACCPT

Valid Different from 0 and less than Original Transaction Number

PART

Valid Original Transaction Number REJCT

If number of Error Transaction error is Then Group Status is

0 ACCPT

Different from 0 and less that Original Transaction Number ACCPT

Equal to Original Transaction Number REJCT


2 SEPAmappings

Technical objectsThe following is a list of ISO controls and dedicated messages:

IsoCode IsoName Additional Information (24 chars.) (French/English)

AC01 IncorrectAccountNumber "COORD. BANC. INEXPLOIT.""Incorrect Account"

AG02 InvalidBankOperationCode "PAYEMENT MODE INVALIDE""Invalid Payment mode"

AM05 Duplication "DOUBLON""Duplicate"

AM10 InvalidControlSum "CALCUL DES TOTAUX""Sum of amounts error"

BE04 MissingCreditorAddress "ADRESSE INVALIDE""Missing Creditor Address"

RC01 BankIdentifierIncorrect "CODE BANQUE INCORRECT""Incorrect Bank Id"

RR01 MissingDebtorAccountOrIdentification "MOTIF REGLEMENTAIRE""Missing Dbtor Account"

RR02 MissingDebtorNameOrAddress "MOTIF REGLEMENTAIRE""Missing Dbtor Name"

RR03 MissingCreditorNameOrAddress "MOTIF REGLEMENTAIRE""Missing Credtr Name"

FF01 Invalid File Format "FORMAT INVALIDE""Invalid format"


2 SEPAmappings

PSR generation (SCT/SDD to PSR mapping: FF01 control)

Overview 46Structure of the SCT/SDD input data 46Structure of the PSR output data 47SCT-PSR and SDD-PSR mapping methods 48

OverviewThe aim is to generate a PSR from either SCT or SDD with FF01 control checking the errors (Syntax, Check constraint, Invalid IBAN or BIC) in the XML input document. If an error is detected, the process generates a PSR document with information from the Group Header whenever this is possible. In cases where the Group Header information is not XML compliant, then no output is generated.

In case of any binary file, the same input document will be routed to the Output.

Structure of the SCT/SDD input dataSCT/SDD comprises three parts:


Group Header

Mandatory, Unique

l Identification of the Order (Id, date)

l Identification of the Corporate (Name, Address. BIC/BEI/CHIPS/DUNS, and so on)

l Control sum of the amount of the whole OrderTotal number of Transactions

Payment Group

Mandatory, Multiple

l Debtor information

l Debtor agent

Transaction Mandatory, Multiple

l Amount, Currency

l Value Date

l 3 Intermediary accounts

Each Transaction is described and belongs to one Payment Group.


2 SEPAmappings

Structure of the PSR output dataPSR comprises three parts:


Group Header

Mandatory, Unique

Identity of the corporate issuing the Payment Order

Group Status

Mandatory, Multiple

The global status of the Payment (RJCT). In this case always Error Code FF01:

l The number of the transaction involved

l The sum of the amount detected in error


2 SEPAmappings

SCT-PSR and SDD-PSR mapping methods

SCT-PSR mapping methodThe following sample diagram shows a simplified view of the mapping structure:

If the input Payment Order is not valid XML, then in the Payment Status Report, information from the Group Header is copied with status "RJCT" and error code as "FF01", along with the reason for failure.

However, if the Payment Order is not valid XML even up to the Group Header level, then flow processing stops and error logs are generated with no output.


2 SEPAmappings

SDD-PSR mapping methodThe following sample diagram shows a simplified view of the mapping structure:

If the input Payment Order is not valid XML, then in the Payment Status Report, information from the Group Header is copied with status "RJCT" and error code as "FF01".

However, if the Payment Order is not valid XML even up to the Group Header level, then flow processing stops and error logs are generated with no output.


3 SWIFT mappings

This chapter describes the libraries for the management of SWIFT Cash Management and Credit Transfer mappings in Axway Financial Standards Library.

Cash Management MT to MX Transformation SR11_01 on page 51

Credit Transfer MT to MX Transformation SR08 on page 54

Credit Transfer MX to MT Transformation SR08 on page 57


Cash Management MT to MX Transformation SR11_01

About Cash Management MT to MX mapping 51Configure B2Bi for Cash Management MT to MX 52Test flows with sample data 53

About Cash Management MT to MX mappingThe mapping libraries enable the transformation of Cash Management MT to MX mapping formats. An example of a Cash Management MT is MT941.

Functional flow

Functional terminology l Cash Management: Refers to a broad area of finance involving the collection, handling, and usage of cash. It involves assessing market liquidity, cash flow, and investments.

Cash Management Messages are part of SWIFT communication in which messages include the letters "MT" (Message Type). This is followed by a 3-digit number that denotes the message category, group and type.

l MT9xx: Defines the Cash Management messages. (9: Cash Management).

l MX messages: Defines the new message type expressed in XML syntax. It is more flexible and easier to implement than the previous generation of message types (MT). These messages are defined as xxxx.nnn.aaa.bb, where:


3 SWIFTmappings

o xxxx is an alphabetic code in four positions (fixed length) identifying the Business Process.

o nnn is an alphanumeric code in three positions (fixed length) identifying the Message Functionality.

o aaa is a numeric code in three positions (fixed length) identifying a particular flavor (variant) of Message Functionality.

o bb is a numeric code in two positions (fixed length) identifying the version.

Cash Management messages are defined as camt.nnn.aaa.bb.

l Map (MT_To_MX): Enables the transformation of Cash Management MT to MX formats. In the map, required fields are mapped and validation of each format is performed, which includes checking of:


o Validation rules applied on each format.


Important:

l The map project delivered with Financial Standards Library 3.9.0 for Cash Management MT to MX mapping uses the new BIC referential delivered with Financial Standards Library 3.9.0.

l To use the new BIC referential or new Custom-Functions, you need to configure Financial Standards Library 3.9.0 on B2Bi.

Configure B2Bi for Cash Management MT to MX 1. Launch the Mapping Services/B2Bi Client.

2. Import the map project (CashManagement_MT_MX_SR11) into the workspace.

3. Deploy the flow (for example, MT900_MX_BkToCstmrDbtCdtNtfctnV02.dmlflw) onto the B2Bi Server.

4. Add the flow (for example, MT900_MX_BkToCstmrDbtCdtNtfctnV02.dmlflw) as a component of MAP type.


a. Sender Id: "SID"





f. Debug: Y



3 SWIFTmappings

6. Create a document service of type Inhouse and add the above deployed flow as a map in it.

7. Create a messaging id of type Inhouse for a partner and virtual partner.



10. Configure any other Cash Management MT to MX flows in the same manner.




3 SWIFTmappings

Credit Transfer MT to MX Transformation SR08About Credit Transfer MT to MX mapping 54Configure B2Bi for Credit Transfer MT to MX 55Test flows with sample data 56

About Credit Transfer MT to MX mappingThe mapping libraries enable the transformation of Credit Transfer MT to MX mapping formats. An example of a Credit Transfer MT is MT101.

Functional flow

Functional terminology l Credit Transfer: Refers to a broad area of finance involving the collection, handling, and usage of cash. It involves assessing market liquidity, cash flow, and investments.

Credit Transfer Messages are part of SWIFT communication in which messages include the letters "MT" (Message Type). This is followed by a 3-digit number that denotes the message category, group and type.




o aaa is a numeric code in three positions (fixed length) identifying a particular flavor


3 SWIFTmappings

(variant) of Message Functionality.


Credit Transfer messages are defined as camt.nnn.aaa.bb.

l Map (MT_To_MX): Enables the transformation of Credit Transfer MT to MX formats. In the map, required fields are mapped and validation of each format is performed, which includes checking of:


o Validation rules applied on each format


Important:

l The map project delivered with Financial Standards Library 3.9.0 for Credit Transfer MT to MX mapping uses the new BIC referential delivered with Financial Standards Library 3.9.0.


Configure B2Bi for Credit Transfer MT to MX 1. Launch the Mapping Services/B2Bi Client.

2. Import the map project (CreditTransfer_MT_MX_SR08) into the workspace.

3. Deploy the flow (for example, MT101_MX_CustomerCreditTransferIniti.dmlflw) onto the B2Bi Server.

4. Add the flow (for example, MT101_MX_CustomerCreditTransferIniti.dmlflw) as a component of MAP type.


a. Sender Id: "SID"





f. Debug Y


6. Create a document service of type Inhouse and add the above-deployed flow as a map in it.

7. Create a messaging id of type Inhouse for the partner and virtual partner.



10. Configure any other Credit Transfer MT to MX flows in the same manner.


3 SWIFTmappings




3 SWIFTmappings

Credit Transfer MX to MT Transformation SR08About Credit Transfer MX to MT mapping 57Configure B2Bi for Credit Transfer MX to MT 58Test flows with sample data 58

About Credit Transfer MX to MT mappingThe mapping libraries enable the transformation of Credit Transfer MX to MT mapping formats. An example of a Credit Transfer MX is pain.001.001.02.

Functional flow

Functional terminology l Credit Transfer: Refers to a broad area of finance involving the collection, handling, and usage of cash. It involves assessing market liquidity, cash flow, and investments.

Credit Transfer Messages are part of SWIFT communication in which messages include the letters "MT" (Message Type). This is followed by a 3-digit number that denotes the message category, group and type.




o aaa is a numeric code in three positions (fixed length) identifying a particular flavor


3 SWIFTmappings

(variant) of Message Functionality.


Credit Transfer messages are defined as pain.nnn.aaa.bb.

l Map (MX_To_MT): Enables the transformation of Credit Transfer MX to MT formats. In the map, required fields are mapped and validation of each format is performed, which includes checking of:


o Validation rules applied on each format


Important:

l The map project delivered with Financial Standards Library 3.9.0 for Credit Transfer MX to MT mapping uses the new BIC referential delivered with Financial Standards Library 3.9.0.


Configure B2Bi for Credit Transfer MX to MT 1. Launch the Mapping Services/B2Bi Client.

2. Import the map project (CreditTransfer_MX_MT_SR08) into the workspace.

3. Deploy the flow (for example, MX_CustCdtTrIni_MT101.dmlflw) onto the B2Bi Server.

4. Add the flow (for example, MX_CustCdtTrIni_MT101.dmlflw) as a component of MAP type.

5. Create a document service of type XML and add the above-deployed flow as a map in it.

6. Create a Metadata Profile with the above-created service.

7. Create a condition in the metadata file such as "ConsumptionFileName Equals <your input file name>".

8. Test this configuration with the input file.

9. Configure any other Credit Transfer MX to MT flows in the same manner.




4 Payments messages

This chapter describes the libraries for the management of X9.37, BAI2, ISO 8583, and NACHA mappings in Axway Financial Standards Library and how to configure them in B2Bi.

X9.37 60Configure B2Bi for X9.37 61

BAI2 62Configure B2Bi for BAI2 63

ISO 8583 64Configure B2Bi for ISO 8583 64

NACHA 65Configure B2Bi for NACHA 65


X9.37The X9.37 format defines the file format that the banks use to exchange images of checks (or in the case of returns, reasons why issuing banks refuse to honor checks). Basically an X9.37 file is a heap of records (variable length). Each record has a type. However, the type does not completely define the definition of the record, some records also get their definition from other parts of the record data.

Since each type of record is variable length, each record is prefixed by a four byte size (big-endian).

All records are EBCDIC text, with the exception of some portions of the image record, which contain a single page TIFF 6.0 file (little-endian). The X9.37 DSTU-2003 standard does describe other formats, but they are no longer acceptable. A check contains two images: an image of the front of the check, and an image of the back of the check. Historical standards were different, so old check images may not follow current standards.


Configure B2Bi for X9.37

Prerequisites 1. Launch Mapping Services and import X9.37 BDoc in a map project.

2. Create an auto flow of X9.37 BDoc.

3. Deploy the above-created auto flow to B2Bi Server.

Configuration in B2Bi 1. Add X9.37 receive JMC as a component of type Document in the Manage components page in

the B2Bi UI.

2. Check the Copy input message if no output created checkbox.

3. Add X9.37 send JMC as a component of type Document in the Manage components page in the B2Bi UI.

4. Add X9.37 flow deployed from Mapping Services as a component of type Document in the Manage components page in the B2Bi UI.

5. Add Copy message as a component of type Map in the Manage components page in the B2Bi UI.

6. Create a document service of type Metadata and add copy message as an Initiating component.

7. Add X9.37 receive JMC as an additional component type after Copy JMC.

8. Add X9.37 flow as an additional component type after X9.37 receive JMC.

9. Add X9.37 send JMC as an additional component type after X9.37 flow.

10. Create a Metadata profile and include the above-created Metadata service in it.

11. Select the Metadata criteria as:Trading Engine: ConsumptionFileName equals <input filename>

12. Place the input test file at the Community Trading Pickup and verify that the file is processed successfully without any errors.


BAI2The BAI2 file format is a specialized and standardized set of codes used for cash management by the Bank Administration Institute (BAI). BAI2 files come to an account holder from a bank. The account holder then imports the files to a bookkeeping application and performs bank reconciliation if necessary.

Bank reconciliation is a process that resolves the difference between the balance on a bank statement and the corresponding amount shown in an enterprise's accounting records. One of the most common applications of the BAI2 file format involves the transmission of returned-check data by a bank to an account holder, an event that nearly always triggers a call for bank reconciliation.


Configure B2Bi for BAI2

Prerequisites 1. Launch Mapping Services and import BAI2 BDoc in a map project.

2. Create an auto flow of BAI2 BDoc.

3. Deploy the above-created auto flow to B2Bi Server.

Configuration in B2Bi 1. Add BAI2 receive JMC as a component of type Document in the Manage components page in

the B2Bi UI.

2. Check the Copy input message if no output created checkbox.

3. Add BAI2 send JMC as a component of type Document in the Manage components page in the B2Bi UI.

4. Add BAI2 flow deployed from Mapping Services as a component of type Document in the Manage components page in the B2Bi UI.

5. Add Copy message as a component of type Map in the Manage components page in the B2Bi UI.

6. Create a document service of type Metadata and add copy message as an Initiating component.

7. Add BAI2 receive JMC as an additional component type after Copy JMC.

8. Add BAI2 flow as an additional component type after BAI2 receive JMC.

9. Add BAI2 send JMC as an additional component type after BAI2 flow.

10. Create a Metadata profile and include the above-created Metadata service in it.




ISO 8583ISO 8583 is the International Organization for Standardization standard for systems that exchange electronic transactions made by cardholders using payment cards.

Configure B2Bi for ISO 8583

Prerequisites 1. Launch Mapping Services and import the ISO8583 BDoc in a map project.

2. Create a 1-1 map and deploy the flow on B2Bi.

3. Add flow and ISO8583 pre-processing and post-processing JMCs as component of type Document in B2Bi.

Configuration in B2BiCreate a Meta Data service and use the above added components in the following hierarchy:

1. Add ISO8583 Receive JMC as initiating step.

2. Add deployed map as an additional processing step.

3. Add ISO8583 Send JMC as an additional processing step.

4. Create a Meta Data Profile and add the above created meta data service to it.




NACHAThe NACHA standard (previously the National Automated Clearing House Association) is defined by the Electronic Payments Association.

The NACHA standard is a flat file based standard for managing the development, administration, and governance of the ACH Network, the backbone for the electronic movement of money and data in the United States.

Configure B2Bi for NACHA

Prerequisites 1. In order to execute NACHA on B2Bi, use a NACHA-enabled license file when installing the B2Bi

Server.

2. Install Mapping Services (B2Bi Client) and Financial Standards Library 3.9.0 with it. For details, refer to the Axway Financial Standards Library Installation Guide.

3. Launch Mapping Services and import any NACHA BDoc in a map project.

4. Create a 1-1 map and deploy the flow on B2Bi Server.

5. Add the deployed flow as a component of type Map in B2Bi.

Configuration in B2Bi 1. Create a document service of type NACHA using the above specified flow.

2. In a Trading Partner and in a Community, create a Messaging ID of type NACHA and enter the Sender and Receiver information in it.

Check that the default Routing ID for both Sender and Receiver is set to the NACHA messaging ID.

3. Create a NACHA inbound agreement and add the NACHA document service to it.

4. Go to the NACHA inbound agreement and set the required Rejection rule for either File or Batch rejection.


4 Payments messages

5. Create an outbound agreement of type NACHA. Go to the Enveloping tab and complete all the required fields in this agreement.



5 Financial Integration Reference Data

About Financial Integration Reference Data 68Usage 68Origin and update of information 68

Using Financial Integration Reference Data (Custom-Functions) 69General information 69BBAN functions 70IBAN and BIC functions 74Extraction from IBAN 80Bank information search 84Version information 88Error handling functions 89Compatibility functions 91

Importing and updating reference data 94Configure B2Bi for the update of reference data 94Reference data file 95Result of import 95Supported Reference Data files 96File name recognition 96IBAN Structure file 98Combined SWIFTRef files 98

Reference Data structure information 99Financial Integration Reference Data database schema 99File to table mapping 102

Banque de France file compiler tool 111Overview 111Usage 111Examples 111

Analysis & migration tool 113Overview 113Command line help 113Analysis mode 114Replacement mode 117



About Financial Integration Reference DataFinancial Integration Reference Data is a service that enables convenient access to key institution information. An institution can be a bank, a branch (of a bank) or a corporate.

It therefore provides information on institutions but also provides the means to convert/verify BICs, IBANs and national accounts.

SWIFT, national banks, and other editors, regularly publish files that provide reference information about institutions. These files come in different formats with a diverse level of information.

UsageFinancial Integration Reference Data can be exploited using a comprehensive set of Custom-Functions. These functions allow you to:

l Validate a BBAN, an IBAN or a BIC

l Find the IBAN matching a BBAN

l Find the BIC matching an IBAN

l Search for institutions (bank/ branch/ corporate) on several criteria

l Get information about a given bank/ branch/ corporate

l Handle errors

For a complete description of the Custom-Functions, see Using Financial Integration Reference Data (Custom-Functions) on page 69.

Origin and update of informationFinancial Integration Reference Data is part of the Axway Financial Standards Library delivery, and as such it does not need extra installation. However, in order to use the service, you need to provide it with reference data, and keep this data up to date. The more the reference data is up to date, the more reliable the service will be.

Currently, Financial Integration Reference Data is able to import data from SWIFT, SWIFTRef, Banque de France and Bundesbank files.

For details of how to import and update reference data, see Importing and updating reference data on page 94.



Using Financial Integration Reference Data (Custom-Functions)

Financial Integration Reference Data can be queried with the help of Custom-Functions that are available in the Financial Standards Library delivery. Because Financial Integration Reference Data is generic, all the functionalities are available, whatever the origin of the reference information.

However, the level of available information depends on the file used to update the reference data directory (each type of file does not contain the same amount of detail).

General information

Overview l Each Custom-Function takes string arguments and returns a string result (except

isResultError, isResultOk and some other old functions that return a Boolean).

l To check whether the result of a Custom-Function is valid or an error message, use the functions isResultError and isResultOk.

l Each function is as flexible as possible:

o The parameters do not need to be padded or trimmed. Each function normalizes its arguments before usage.

o Most secondary parameters are optional. If not set (null, empty or blank), a default value is used (for example, if you do not indicate the country code for the GetIbanForBban, "FR" is automatically used).

l You can cascade calls to functions and control only the final status (you do not need to check the status on each call). The cascading errors are filtered to keep only the original error.

l Certain parameters are optional

o If a parameter is set with a value null, empty, or blank, it is considered as not set and the default value for this parameter is used.

The following sections describe the Custom-Functions as they appear in Integrator. Generally, the corresponding Java function has the same spelling, except that the first letter is lower-case.

Expiration dateThis is an important notion to understand as it has caused confusion among developers. Only a few reference data file types handle expiration dates, but in all cases:

l The next DELTA update will explicitly remove expired records.

l The next FULL update will not contain expired records (implicit removal).



As such, expired records are transient and cannot be tracked. That is why the custom functions engine considers expired records as non-existent and hides them. Any update of the reference data physically removes them.

This behavior should not be changed.

BBAN functionsBBAN stands for Basic Bank Account Number. It is a national account number. The IBAN usually encapsulates the BBAN and just adds a country code and a checksum.

In France and Monaco, the BBAN is also called a RIB (Relevé d'Identité Bancaire).

Functions that contain the word "Rib" in their name only apply to a French or Monegasque BBAN (RIB).

GetRibKey

Description This function computes the key of a RIB, given the bank ID, the branch ID and the account number.

Parameters l bankId (string): The bank identifier (value between 1 and 99999)

l branchId (string): The branch identifier (value between 0 and 99999)

l accountNb (string): The account number (can contain letters and numbers; not case sensitive). It must not have more than 11 characters (leading zeros ignored), and cannot be 0.

Result l (String) The 2-digit key if it could be computed

l (String) An error message if the key could not be computed

Example l GetRibKey("10011", "20", "1203043216V ") returns "93"

DB usage None

Replaces GetRIBKey



GetRib

Description This function computes a RIB, given the bank ID, the branch ID and the account number.

Parameters l bankId (string): The bank identifier (value between 1 and 99999)

l branchId (string): The branch identifier (value between 0 and 99999)

l accountNb (string): The account number. It can contain letters and numbers. It is case sensitive. It must not have more than 11 characters (leading zeros ignored), and cannot be 0.

Result l (String) The 23 characters of the RIB if it could be computed

l (String) An error message if the key could not be computed

Example l GetRib("10011", "20", "1203043216V") returns "10011000201203043216V93"

DB usage None

IsValidRib

Description This function verifies the validity of a RIB and returns "OK" if the RIB is valid (size, content and key).

Parameters l rib (string): The RIB to verify. It can contain delimiters (space, '.', '-')

Result l (String) OK if the RIB is valid (components, size and key)

l (String) Error message if the RIB is not valid (explains where the problem is)

Example l IsValidRib(" 126.190 002-30002 314670472") returns "OK"

l IsValidRib("11749000010002314670437") returns ""11749000010002314670437" is invalid: Wrong

checksum"

DB usage None



RibForDisplay

Description This function takes a RIB and returns a standardized, user-friendly representation (bank ID, branch ID, Account number and Key are each separated by a space).

Parameters l rib (string): The RIB to standardize. It can contain delimiters (space, '.', '-')

Result l (String) The standardized RIB (bank, branch, account number and key are separated by a space)

l (String) Error message if the RIB could not be standardized. Note that this function only checks the size of the RIB, not its validity.

Example l RibForDisplay("126.190002-30002 314670472 returns "12619 00023 00023146704 72"

DB usage None

GetDkn

Description This function computes a DKN (Deutsch KontoNummer) when given the bank sort Id and the account number.Note: Only the format of the DKN is controlled, not the existence of the Bank Sort ID nor the checksum of the account number.

Parameters l bankSortId (string): The bank identifier. It must contain 8 significant digits

l accountNb (string): The account number. It can only contain digits and its value must be greater than 0 and less than 10 significant digits

Result l (String) The 18 characters of the DKN if it could be computed

l (String) An error message if the DKN could not be computed

Example l GetDkn (" 037040044 ", " 000532013000") returns "370400440532013000"

DB usage None



DknForDisplay

Description This function takes a DKN (Deutsch KontoNummer) and returns its user-friendly representation (bank Sort Id and Account number separated by a space)

Parameters l dkn (string): the DKN to beautify. It can contain delimiters (space, '.', '-')

Result l (String) the beautified DKN (bank sort Id and account number are separated by a space)

l (String) Error message if the DKN could not be beautified. Note that the function will only check the size of the DKN, not its validity

Example l DknForDisplay("3704 004405-32013 0.00") returns "37040044 0532013000"

DB usage None

IsValidBban

Description This function checks whether a BBAN (Basic Bank Account Number) is valid or not.Note: If the provided country code is FR or MC, this function is equivalent to the isValidRib function. The validity is checked by trying to compute the corresponding IBAN. If it succeeds, the BBAN is considered valid.

Parameters l bban (string): The BBAN to verify. It can contain delimiters (space, '.', '-')

l countryCode (string): optional The ISO country code of the country. If not provided, FR is assumed

Result l (String) OK if the BBAN is valid (size and key)

l (String) Error message if the BBAN is not valid (explains where the problem is)

Example l IsValidBban("510-0075470-61", "BE") returns "OK"

DB usage ibanstructure



IBAN and BIC functionsIBAN stands for International Bank Account Number. It is an encapsulation of a national BBAN that makes it international. Here is the format of an IBAN:

CCKKBBBBBBB...

Where:

l CC is the ISO country code

l KK is a checksum key

l BBBBBB... is the national BBAN. The length of the BBAN depends on the country

BIC stands for Bank Identifier Code. This code is controlled and issued by SWIFT. It is assigned to banks for their connectivity to the SWIFT network.

l The BIC is 8 characters long. If a BIC is associated with the branch code, it is 11 characters long. The functions handle both 8-character and 11-character BICs. If the submitted BIC is 8 characters long, it is automatically padded with XXX.

l In fact, not only financial institutions have an identifier. Some corporates also have one in order to connect to SWIFT. Corporate identifiers are known as BEI (Business Entity Identifier).

o If the institution is a bank, the BIC will hold a real Bank Identifier Code

o If the institution is a corporate, the BIC will hold a Business Entity Identifier

o See GetSubType for more information

GetIbanForBban

Description This function computes the IBAN corresponding to the given BBAN.

Parameters l bban (string): The BBAN to include in the IBAN. It can contain delimiters (space, '.', '-')

l countryCode (string): optional The ISO country code of the country. If not provided, FR is assumed (FR also works for Monaco)

Result l (String) The corresponding IBAN if it could be computed

l (String) Error message if the IBAN could not be computed (explaining the reason)



Example l GetIbanForBban("12739.00073.00023146704.88",

"FR") returns "MC5812739000730002314670488". This is a Monaco exception. Initially FR was assumed, but the correct country code is MC.

l GetIbanForBban("510-0075470-61", "ZZ") returns "ERROR: Can't build IBAN for BBAN "510-0075470-

61" of country "ZZ": No country code matches

"ZZ""


Replaces GetIBAN

IsValidIban

Description This function checks whether an IBAN is correct or not. It verifies the country and the length. Additionally, if it is a French (or Monaco) IBAN, it checks the validity of the RIB it contains.

Parameters l iban (string): The IBAN to verify. It can contain delimiters (space, '.', '-')

Result l (String) OK if the IBAN is valid

l (String) Error message if the IBAN is not correct (explains where the problem is)

Example l IsValidIban("ES73-2100.3012 8121 0391 0688") returns "OK"




IbanForDisplay

Description This function takes an IBAN and displays it in a standardized, user-friendly representation: 1 space is inserted every 4 characters.

Parameters l iban (string): The IBAN to standardize. It can contain delimiters (space, '.', '-')

Result l (String) The standardized IBAN

l (String) Error message if the IBAN could not be standardized

Example l IbanForDisplay("ZZ73-2100.30128121 03-91088") returns "ZZ73 2100 3012 8121 0391 088". This is not a valid IBAN, but the scope of the function is not to validate the IBAN.

DB usage none

GetBicForIban

Description This function takes an IBAN and returns its corresponding BIC (if any).The BIC returned is always a BIC11. If it was initially a BIC8, it is padded with XXX.

Parameters l iban (string): The source IBAN

Result l (String) The corresponding BIC11

l (String) Error message if an error occurred, or if no matching bank was found

Example l Valid IBAN:getBicForIban("FR2820041000012108331V02042") returns PSSTFRPPPAR

l IBAN is unknown:getBicForIban ("AT658888800234573201") returns ERROR: Can't retrieve BIC from IBAN

"AT658888800234573201": No entity corresponds

to this IBAN

DB usage ibanstructure, bicibandir



Replaces GetBICForIBAN

GetRoutingBicForIban

Description This function takes an IBAN and returns its corresponding Routing BIC (if any).In most cases, it is identical to the BIC. It can differ if the institution is absorbed by another one. The Routing BIC is then the one of the absorbing institution.

Parameters l iban (string): The source IBAN

Result l (String) The corresponding Routing BIC11


Example l GetRoutingBicForIban

("MC5812739000730002314670488") returns "CFMOMCMXXXX"


GetServicesForIban

Description This function takes an IBAN and returns the list of services provided by the corresponding institution.

Parameters l iban (string): The IBAN of the bank/branch

Result l (String) The comma-separated list of services that the institution offers


Example l GetServicesForIban("ES7321003012812103910688") returns "EBA,ERP,FIN,SCO,TGT"




ContainsServices

Description This function helps to check whether given services are contained in a service list.

Parameters l ServiceList (string): The comma-separated list of services provided by the institution (result of GetServicesForIban() and content of Services field)

l requestedServices (string): The comma-separated list of requested services

Result l (String) OK if all requested services are contained in the service list.

l (String) Error message if at least one of the requested services could not be found in the service list.

Example l ContainsServices("EBA,ERP,FIN,SCO,TGT",

"ERP,TGT,FIN") returns "OK"

l ContainsServices("EBA,ERP,FIN,SCO,TGT",

"ERP,FOO,FIN") returns "ERROR: Service "FOO" not found!"

Services See table below for a non-exhaustive list of services


Non-exhaustive list of services (for ContainsServices)

Service code Definition

SCT SEPA Credit Transfer

SDC SEPA Direct Debit Core

SDB SEPA Direct Debit B2B

TGT Target2 direct participant

TG+ Target2 indirect participant

EBA EBA clearing – Euro1

EB+ EBA clearing – Euro1 / step1 reachable institution



Service code Definition

ABE EBA clearing – Euro1 / step1 (EBA)

ERP EBA clearing – Step1

IsExistingBic

Description This function checks whether a BIC exists. The type of BIC (BIC or BEI) is of no importance.

Parameters l bic (string): The BIC to search

Result l (String) OK if it exists.

l (String) Error message if it could not be found (with the reason)

Example l IsExistingBic("PSSTFRPP") returns "OK"

l IsExistingBic("FOOBARRR") returns "ERROR: BIC "FOOBARRR" does not exist"

DB usage bicibandir

GetSubType

Description This function returns the type of a BIC (real BIC, BEI or NONE if it does not exist).

Parameters l bic (string): The BIC to search

Result l (String) BIC if it is a Bank Identifier Code, BEI if it is a Business Entity Identifier (corporate…), NONE if it could not be found

l (String) Error message if something went wrong during the search

Example l GetSubType("PSSTFRPP") returns "BIC" > Banque Postale, which is a financial institution

l GetSubType("VAEOFRPPXXX") returns "BEI" > Valeo, which is a Business institution (not a bank)

l GetSubType ("FOOBARRR") returns "NONE" > Does not exist

DB usage bicibandir



Extraction from IBANThe following functions help extract information from an IBAN.

The IBAN must belong to a recognized country. The functions normalize the IBAN before checking its length and perform an evaluation, but no other validation is done. To fully validate an IBAN, use IsValidIban.

The built-in IBAN cache makes any subsequent extraction from the same IBAN very efficient.

GetCountryCodeFromIban

Description This function extracts the country code from an IBAN and returns it.

Parameters l iban (string): The IBAN. Can contain delimiters.

Result l (String) The country code extracted from the IBAN

l (String) Error message if an error occurred

Example l GetCountryCodeFromIban

("FR2820041000012108331V02042") returns "FR"

l GetCountryCodeFromIban("DE893 7-040044.053201

3000") returns "DE"


GetBankIdFromIban

Description This function extracts the bank ID from an IBAN and returns it.


Result l (String) The bank ID extracted from the IBAN


Example l GetBankIdFromIban

("FR2820041000012108331V02042") returns "20041"

l GetBankIdFromIban("DE893 7-040044.053201 3000") returns "37040044"




GetBranchIdFromIban

Description This function extracts the branch ID from an IBAN and returns it.


Result l (String) The branch ID extracted from the IBAN. If the IBAN has no branch ID, then an empty string is returned.


Example l GetBranchIdFromIban

("FR2820041000012108331V02042") returns "00001"

l GetBranchIdFromIban("DE893 7-040044.053201

3000") returns "" because the German BBAN does not handle branches


GetAccountNbFromIban

Description This function extracts the account number from an IBAN and returns it. The returned account number can contain the key. For finer extraction, see country specific functions (for example GetRibAccountNbFromIban & GetRibKeyFromIban


Result l (String) The account number extracted from the IBAN.


Example l GetAccountNbFromIban

("FR2820041000012108331V02042") returns "2108331V02042"

l GetAccountNbFromIban("DE893 7-040044.053201

3000") returns "0532013000"




GetRibAccountNbFromIban

Description This function extracts the RIB account number from an IBAN and returns it. This is the French (or Monegasque) account number, without the key.For generic account number extraction, see GetAccountNbFromIban.


Result l (String) The account number extracted from the IBAN.

l (String) Error message if an error occurred.

Example l GetRibAccountNbFromIban

("FR2820041000012108331V02042") returns "2108331V020"

l GetRibAccountNbFromIban("DE893 7-040044.053201

3000") returns "ERROR: Can't get RIB Account Nb from IBAN "DE893 7-040044.053201 3000": Can't

get a RIB account number from a non French BBAN

(DE)!"


GetRibKeyFromIban

Description This function extracts the RIB Key from an IBAN and returns it. For generic account number extraction, see GetAccountNbFromIban.


Result l (String) The RIB key extracted from the IBAN.


Example l GetRibKeyFromIban

("FR2820041000012108331V02042") returns "42"

l GetRibKeyFromIban("DE893 7-040044.053201 3000") returns "ERROR: Can't get RIB Key from IBAN "DE893 7-040044.053201 3000": Can't get a RIB key from

a non French BBAN (DE)!"




GetNationalIdFromIban

Description This function extracts the national id from an IBAN and returns it (usually, it is the concatenation of Bank Id and Branch Id).


Result l (String) the national ID extracted from the IBAN.


Example l GetNationalIdFromIban

("FR2820041000012108331V02042") returns "2004100001"

l GetNationalIdFromIban("DE893 7-040044.053201

3000") returns "37040044"


Replaces GetNationalCodeForIBAN



Bank information searchAs there is more information than just BIC and IBAN in the reference data repository, two additional functions help exploit all available information.

The SearchBank function allows the searching of records matching search criteria. The GetBankInfo function reads the records (field by field or as a whole).

SearchBank

Description This function returns a list of bank/branch record IDs that match the given search criteria.

Parameters (String): The list of criteria in the form <fieldName>=<value> where:

l <fieldname> is a known field name (see Searchable fields below)

l <value> is the searched value. It can contain wildcards (*). See examples below

l Each criteria is separated by a semi-colon

l At least one parameter must be provided

Result l A semi-colon separated list of record IDs corresponding to the records that match the search criteria. GetBankInfo can then be used to get information on each record.

Example l SearchBank("bankName=CREDIT*;city=LA

MAS*;addressL1=*Gabriel") returns "AD000054" - Only one result for this search

l "SearchBank("bankName=CAIXA*DE

DEPOSITOS;city=Paris") returns "FR000703;FR048767;FR048768;FR048769;FR048776;

FR048783;FR048790" - Seven matching results for this search

DB usage bicibandir



Searchable fields (for SearchBank)The following fields can all be used as part of the search criteria. The fields in bold are searched very fast because they are indexed.

Field Description

countryCode The ISO country code (FR, ES…). No wildcard, 2 letters only

nationalId The national ID of the bank (concatenation of the bank ID and branch ID). Wildcards allowed.

Bic The BIC11. Wildcards allowed (for example to search on BIC8)

RoutingBic The Routing BIC11. Wildcards allowed

chipsUid The CHIPS Universal Identifier. Wildcards allowed

subtype The institution’s sub type (as defined by SWIFT)

bankName The bank name. Wildcards allowed

branchName The branch name. Wildcards allowed

addressL1 Address line 1. Wildcards allowed



city The city. Wildcards allowed

zipCode The Zip Code. Wildcards allowed

country The country name. Wildcards allowed

services The services offered. Wildcards allowed

updateDateStr The update date in format yyyyMMdd. Wildcards allowed

expirationDateStr The expiration date in format yyyyMMdd. Wildcards allowed

Note:

l recordKey and ibanKey can also be part of the search criteria. But it does not make much sense, because there are other functions that enable you to search more efficiently on these criteria.



l All fields that appear as a result of a call to GetBankInfo can be searched, plus countryCode and nationalId that are provided for convenience (more understandable than ibanKey that they compose)

GetBankInfo

Description

This function returns information on a bank/branch record, given its record number.Note: See GetBankInfoAdvanced for advanced queries.

Parameters

l recordId (String): The record identifier of the institution to read

l field (String): optional The field to look for (case sensitive). If empty, gives the whole record information.

Result l The information if it could be found (either the whole record, or the searched field)

l Error message if no record matches the recordId, or if there was an error

Example 1 GetBankInfo("AD000049") returns "recordKey=AD000049|ibanKey=AD00030016|bic=CRDAADADXXX| routingBic=CRDAADADXXX|chipsUid=016179|subType=| bankName=CREDIT ANDORRA|branchName=FITER I ROSSELL| addressL1=22, AV. FITER I ROSSELL|addressL2=| addressL3=| city=ESCALDES-ENGORDANY|zipCode=| country=ANDORRA| services=TGT,SCT|updateDateStr=20100807| expirationDateStr=20600807"

Example 2 GetBankInfo("AD000049","branchName") returns "FITER I ROSSELL"

DB usage bicibandir



GetBankInfoAdvanced

Description

This function returns information on the first bank/branch record matching a record number, an IBAN or a BIC.Only a search on the record number guarantees the uniqueness.

Parameters

l IdValue (String) : By default, this will be the record identifier of the institution to read, but it can also be a BIC, or an IBAN key

l field (String): optional The field to look for (case sensitive). If not specified, gives the whole record information

l separator (String): optional The field separator to use (by default, the '|' character)

l index (String): optional The index to use. By default, it is RECORD (to search on the unique record key). It can also be BIC to search on the BIC, or IBAN_KEY to search on the IBAN key (Country code + National Id).


l Error if nothing matches the request, or if there was an error

Example 1 GetBankInfoAdvanced("AD00030016","","","IBAN_KEY") returns "recordKey=AD000049|ibanKey=AD00030016|bic=CRDAADADXXX| routingBic=CRDAADADXXX|chipsUid=016179|subType=| bankName=CREDIT ANDORRA|branchName=FITER I ROSSELL| addressL1=22, AV. FITER I ROSSELL|addressL2=|addressL3=|city=ESCALDES-ENGORDANY|zipCode=|country=ANDORRA| services=TGT,SCT|updateDateStr=20100807| expirationDateStr=20600807"

Example 2 GetBankInfoAdvanced("CRDAADADXXX","branchName","","BIC") returns "FITER I ROSSELL"

DB usage bicibandir



Version informationA special record tracks the reference data changes. It helps keep the data consistent, and the internal caches aligned with the database. The GetTableInfo function is provided to read this tracking record.

GetTableInfo

Description This function returns the Reference Data table information: Date and type of update, file that was used to update, etc.

Parameters l field (String): optional The field looked for (case sensitive). If not specified, gives all the record information.


l Empty string if nothing matches the request, or if there was an error

Example l GetTableInfo("") returns "File=BI_GENERIC.TXT|Version=20121008|FileType=

BIC+IBAN|Type=FULL|Updates=1|First=20121008|

Last=20121008|Inserted=6|Updated=0|Deleted=0"

l GetTableInfo("File") returns "BI_GENERIC.TXT"

DB usage bicibandir

Fields (for GetTableInfo)

Field Description

File Name of the last imported file

Version Date (yyyymmdd): Version of the file as read on its filename

FileType Type of file used for the import(s). Possible values: "BIC+IBAN", "FGD", "IBAN+", "IBAN+ V2", "IBAN+ V3", "BANK DIRECTORY+", "BANK DIR+ V2", "BANK DIR+V3", "IBAN & BANK DIR+", "BLZ".

Type Type of the last import operation (FULL or DELTA)

Updates Number of total updates (Initial full import is the first)



Field Description

First Date (yyyymmdd): Date of the last full update

Last Date (yyyymmdd): Date of the last update (full or delta)

Inserted Number of inserted records on last import operation

Updated Number of update records on last import operation

Deleted Number of deleted records on last import operation

Error handling functions

IsResultError

Description This function checks whether the result of a function call is an error or not. You should use this function, or IsResultSuccess, to verify the validity of a result. (IsResultSuccess is not the exact symmetry of IsResultError).

Parameters funcResult (string): The function result to analyze

Result (Boolean) True if the result is an error, False otherwise

Example l IsResultError("ERROR: This is an error") returns True.

l IsResultError("Correct Value") returns False.

l IsResultError("") returns False.

DB usage none



IsResultSuccess

Description This function checks whether the result of a function call is valid or not. This is not the exact opposite of IsResultError as it will also check if the result is not empty (or blank or null).

Parameters funcResult (string): The function result to analyze

Result (Boolean) True if the result is not an error and contains information (not null, blank, or empty), False otherwise

Example l IsResultSuccess("ERROR: This is an error") returns False.

l IsResultSuccess("Correct Value") returns True.

l IsResultSuccess("") returns False.

DB usage none



Compatibility functionsThe following functions are provided for migration purposes only.

They take a split BIC as input (bank code, branch code) and return a Boolean or a String. They are fully compatible with the older functions that they replace. When writing new expressions, it is recommended to use the new functions described in the previous section because they provide error control, and do not need a split BIC as input.

IsBicOrBeiLcBcExtended

Description This function returns the following values:

l OK if the provided BIC exists, for both financial and non-financial BIC (BEI)

l KO if the provided value does not exist

l a specific error message which describes the error (for example, when the database could not be accessed)

Compatibility The input and output are 100% compatible

Parameters l bankCode (String): The first 8 digits of the BIC

l branchCode (String): The last 3 digits of the BIC (optional)

Return type String

Advantage of new function

Much faster (uses a cache) and flexible.

Replaces IsBicOrBeiLcBc



IsBicOrBeiLcBc

Description This function returns true if the provided BIC exists, for both financial and non-financial BIC (BEI)




Return type Boolean



Replaces IsKeyPresentBic

Notes When writing a new expression, it is recommended to use IsExistingBic

IsBeiLcBc

Description This function returns true if the provided BIC exists, and is a non-financial BIC (Business Entity Identifier or BEI).






Replaces SWCheck_BIC2

Notes When writing a new expression, it is recommended to use GetSubType which returns the type of the BIC



IsValidBICIBAN

Description This function returns true if the BIC – IBAN pair is valid.


Parameters l BIC (String): BIC of the pair to compare

l IBAN (String): IBAN of the pair to compare

Example isValidBicIban("CRDAADADXXX",

"FR2820041000012108331V02042") returns false because this IBAN does not correspond to the BIC



Importing and updating reference data

Configure B2Bi for the update of reference dataThe Reference Data Repository is updated by a flow provided by the JMC component. This is an unsynchronized import. The import file is placed in a folder and a result file is generated when the job is done.

1. Launch Mapping Services/B2Bi Client.

2. Import the map project (Reference Data) into the workspace.

3. Deploy the flow (ReferenceData) onto the B2Bi Server.

4. Create an Application Pickup of type Application FTP (provide a directory location for the file pickup or keep the default one).

5. Register DataManagementJMC. For details, see Register JMC on B2Bi on page 124.

6. Add the following components to B2Bi in the order below:

a. DataManagementJMC as MAP type and add the following line in the service Configuration tab at operation class: com.axway.fex.mapping.basics.biciban.BicIbanImportOperati

on

This line must be added at service level, after the service has been created.

b. Flow as Document type.

7. Create a Service of type Metadata and add the above map as component in service and select the Application Delivery.

8. Add the flow as Document type.

9. Create a Metadata Profile.


b. In Criteria, select the following as per Reference Data File Name (see File name recognition on page 96):


Integration Engine: FTP RemoteFileName equals IS.TXT

In this example, IS.TXT is the Input reference Database file for SWIFT IBAN Structure v1.

10. Update the Reference Data Repository with this configuration by adding the reference data file in the Application FTP location.



Reference data fileB2Bi Server automatically recognizes the type of file from its name and applies the appropriate import process. If the file type is unknown, it will report an error in the result file.

For a list of supported data files, see Supported Reference Data files on page 96.

Result of importIf the import was successful:

l The Financial Integration Reference Data is updated with the content of the imported file.

l An XML import report is given as output, indicating how many records were affected.

l The table tracking info is updated

If the import failed:

l The Financial Integration Reference Data stays in the state it was before the import.

l The XML import report gives details of the nature of the failure.

The following report shows the typical successful import of an IBAN structure file:

<FexProcessingResults>

<DataAccessProcessingResults>


<NumberRecordsUpdated>0</NumberRecordsUpdated>

<NumberRecordsRemoved>0</NumberRecordsRemoved>

</DataAccessProcessingResults>

<ResultSummary>

<Status>SUCCESS</Status>

<Message>File=IS.TXT, Version=20121129, FileType=IBAN STRUCTURE,

UpdateType=FULL, UpdateCount=0, First=20121129, Last=20121129,

Inserted=53, Updated=0, Deleted=0</Message>

</ResultSummary>

</FexProcessingResults>

The Message tag contains the table information summary.

In case of error, the Message tag will contain the error message.



Supported Reference Data filesCurrently, Financial Integration Reference Data can import the files listed in this section. These files do not all contain the same amount of information. Check the description and usage in the following table to check if it matches your needs.

Origin File Full/Delta Description and usage

SWIFTRef IBAN Structure v2

Full & Delta IBAN structure information, which is mandatory for manipulation of IBANs.Supports IBAN structure Full and Delta files.

SWIFTRef IBAN+ v3 Full & Delta Perfect for IBAN to BIC conversion. V3 is lighter than preceding versions (lots of fields removed). Not suited to get information on banks and branches.

SWIFTRef Bank Directory+ v3

Full & Delta Contains all information about banks. V3 shows a come back to the BIC+IBAN standard. Not suited for IBAN to BIC conversion (except SEPA services).

SWIFTRef Combined IBAN+ & Bank Directory+ v3

Full Combines the information from the V3 SWIFTRef files. Allows IBAN to BIC conversion, BIC validation, and gives complete information on banks/branches.

Banque de France

FGD Full & Delta Only for France and Monaco. Allows IBAN to BIC conversion, BIC validation, and gives complete information on banks/branches. Does not indicate the offered services

Bundesbank BLZ v1 & v2 Full & Delta Only for Germany. Allows IBAN to BIC conversion, BIC validation, and gives partial information on banks (city but no address). Does not indicate the offered services.

For information about the mapping done for each file, and the information that is available per file, see Reference Data structure information on page 99.

File name recognitionThe file name must have the following structure:

<Prefix>[<Version>][<Update mode>][<Date>].<ext>



l <Prefix> determines the type of the file

l <Version> indicates the version of the file (if none, it is a V1)

l <Update mode> is either FULL or DELTA. If not indicated, it is a FULL update

l <Date> indicates the date of the file (to know how up-to-date it is). If not indicated, the date of import is used instead

l <ext> is the extension (usually dat or txt)

Prefix Corresponding type of data

IBANPLUS_V3 SWIFTRef IBAN+ v3

BANKDIRECTORYPLUS_V3 SWIFTRef Bank Directory+ v3

FGD Banque de France "Fichier des Guichets Domiciliataires"

BLZ Bundesbank "Bankleitzahlendateien"

IBANSTRUCTURE_V2 SWIFTRef IBAN Structure v2

If the file is recognized and compatible with the current Reference Data state, its content is imported and the Financial Integration Reference Data table is updated.

l It is allowed to do a DELTA update only on the same type of data

l A FULL update erases the current data, whatever type of data was in the table

l It is mandatory to import an IBAN Structure file and a valid directory file before being able to use any Custom-Function related to the Financial Integration Reference Data

l Reference Data is cached for efficiency. The version of the cache is checked regularly (every 2 minutes). If versions do not match, the cache is cleared. So the data changes are only fully applied 2 minutes maximum after their successful import.

l For a quick comparison of the file characteristics, see Supported Reference Data files on page 96.



IBAN Structure fileThe IBAN Structure file must be imported first. For efficiency, it is placed and kept in memory upon first usage. If you need to import a new IBAN Structure file, restart Integrator so that it refreshes its cache.

Combined SWIFTRef filesIf a Bank Directory+ v3 FULL is imported upon a same version of IBAN v3 FULL file, both files are merged, resulting in a reference data table as rich as the one generated by a BIC + IBAN import.

l Only works with an IBAN+ v3 import followed by a Bank Directory+ v3 import

l Both files must have the same date (in the file name)

l Both files must be FULL update files



Reference Data structure information

Financial Integration Reference Data database schema

IBAN structure tableHere is the structure of the IBAN structure table (ibanstructure). This table is necessary to create and validate IBANs and BBANs.

Name Type Index Comment

Key

RecordKey A17 I0 Unique key on RecordKey

Structure information

CountryCode A2 ISO country code

NationalIdPos I11 - Position of the national ID (equals BankIdPos)

NationalIdLen I11 - Length of the national ID. The start position is BankIdPos.

BankIdPos I11 - Position of the Bank ID in the IBAN

BankIdLen I11 - Length of the Bank ID in the IBAN

BranchIdPos I11 - Position of the Branch ID in the IBAN

BranchIdLen I11 - Length of the Branch ID in the IBAN

AccountNumPos I11 - Position of the Account number in the IBAN

AccountNumLen I11 - Length of the Account number in the IBAN

IbanTotalLen I11 - Total length of the IBAN

Information about the version, status and latest updates will be written in the structureinfo table within the same database.



Bank information tableThe reference data is stored in this table (bicibandir), whatever its origin (SWIFT, SWIFTRef, Banque de France).


File maintenance & keys

RecordKey A17 I0 Unique key for the institution. Corresponds to the record key in the file

Identification

Ibankey A17 I1 The concatenation of the country code and national ID

Bic A11 I2 The BIC 11 code chosen among the available ones

RoutingBic A11 - The BIC 11 to route to (when no routing, equal to Bic)

Chipsuid A6 - The CHIPS Universal ID, when available

Subtype A4 - Bank/branch sub-type - Gives the type of the institution

Address

Bankname A200 I3 The name of the bank

Branchname A120 I3 The name of the branch of the bank

Addressl1 A160 - 1st line of the branch address

Addressl2 A160 - 2nd line of the branch address

Addressl3 A160 - 3rd line of the branch address

City A70 - City where the branch of the bank is

Zipcode A40 - ZIP code associated with the City

Country A70 - Country name (corresponds to Country code)




Services A100 - Comma-separated list of services offered by the institution

Dates

Updatedate A8 - Date when the record was last updated

Expirationdate A8 - Date after which the record should not be used anymore

l The BIC takes the following value in order of preference:

o The IBAN BIC if provided

o The BIC (BICLocal Code + BICBranch Code)

o See the detail on each file format for more information

l If the BIC is only 8 characters long, it is padded with XXX

l If not set, the Routing BIC takes the value of the BIC

l If a file address field does not fit in length in the table, all address fields are combined and split automatically to fit the table address fields

l When there is no expiration information, the Expirationdate is set to Updatedate + 50 years.

l When the country is not available, it is deduced from the BIC:

o All French territories are considered as FRANCE

o An exception is the Monaco territory that is considered as MONACO

PerformanceAn information cache is used to speed up recurrent searches: Every record read from the table is cached. That way, a next search on that same record uses the cache and does not query the database.

The cache has a limited size. For efficiency reasons it only keeps the most frequently accessed records.

An automatic refresh occurs every 2 minutes. So after an update, even in a cluster, all caches will be up-to-date within two minutes.

The IBAN Structure is an exception as it is very static. For more information, see IBAN structure table on page 99.



File to table mappingThe Financial Integration Reference Data is generic, meaning that a mapping needs to be done between each importable file format to make it fit the generic table.

So this is an approach where all the mapping work is done at import time. After it has been imported, the data is ready for use, which guarantees efficiency in everyday usage.

BIC + IBANThis SWIFT file format is deprecated since January 2012. It is still the most complete directory.

The corresponding filename prefix is BI. For details, see Importing and updating reference data on page 94.

BicIbanDir table BICPlusIBAN BI file


RecordKey RECORD_KEY (BI3)

Identification

Ibankey IBAN COUNTRY CODE (BI19) + IBAN NATIONAL ID (BI20)

Bic IBAN BIC or BIC

RoutingBic ROUTING BIC or Bic

Chipsuid CHIPS UID (BI24)

Subtype SUBTYPE INDICATOR (BI25)

Address

Bankname INSTITUTION NAME (BI4)

Branchname BRANCH INFORMATION (BI6)

Addressl1 PHYSICAL ADDRESS 1 (BI29)

Addressl2 PHYSICAL ADDRESS 2 (BI30)

Addressl3 PHYSICAL ADDRESS 3 (BI31) + PHYSICAL ADDRESS 4 (BI32)

City CITY HEADING (BI5)



BicIbanDir table BICPlusIBAN BI file

Zipcode ZIP CODE (BI33)

Country COUNTRY NAME (BI35)

Services SERVICE CODES (BI26)

Dates

Updatedate UPDATE DATE (BI41)

Expirationdate NATIONAL ID EXPIRY DATE (BI40) or UPDATE DATE + 50 years

IBAN+ v3This is a new SWIFTRef format introduced in February 2012, to replace partially BIC + IBAN.

It only includes information to make the correspondence between an IBAN and a BIC.

The corresponding filename prefix is IBANPLUS_V3. For details, see Importing and updating reference data on page 94.

BicIbanDir table IBAN + v3 File


RecordKey RECORD_KEY (2)

Identification

Ibankey IBAN ISO COUNTRY CODE (6) + IBAN NATIONAL ID (9)

Bic IBAN BIC (7)

RoutingBic ROUTING BIC (8) or Bic

Chipsuid -

Subtype -

Address

Bankname INSTITUTION NAME (3)

Branchname -

Addressl1 -



BicIbanDir table IBAN + v3 File

Addressl2 -

Addressl3 -

City -

Zipcode -

Country COUNTRY NAME (4)

Services SEPA info from field 10

Dates

Updatedate Update time as read in file name, or import time

Expirationdate Updatedate + 50 years

Bank Directory+ v3This is a new SWIFTRef format introduced in February 2012, to partially replace BIC + IBAN.

It only includes information on institutions (banks, branches, corporate).

The corresponding filename prefix is BANKDIRECTORYPLUS_V3. For details, see Importing and updating reference data on page 94.

BicIbanDir table Bank Directory+ v3 File


RecordKey RECORD KEY (2)

Identification

Ibankey ISO COUNTRY CODE (30) + NATIONAL ID (17)

Bic BIC (15)

RoutingBic -

Chipsuid CHIPS UID (16)

Subtype SUBTYPE INDICATOR (32)



BicIbanDir table Bank Directory+ v3 File

Address

Bankname INSTITUTION NAME (19)

Branchname BRANCH INFORMATION (20)

Addressl1 STREET ADDRESS 1 (22)

Addressl2 STREET ADDRESS 2 (23)

Addressl3 STREET ADDRESS 3 & 4 (24 & 25)

City CITY (26)

Zipcode ZIP CODE (28)

Country COUNTRY NAME (29)

Services SERVICE CODES (35)

Dates


Expirationdate Updatedate + 50 years

Combined IBAN+ and Bank Directory+It is possible to combine a full update with IBAN+ v3 and a full update with Bank Directory+ v3.

l By combining the contents of these two files it is possible to get a content equivalent to the former BIC + IBAN file

l Both files must be of the same version (same date and version)

SWIFTRef v3

BicIbanDir table

Bank Directory+ v3 file IBAN + v3 file


RecordKey RECORD_KEY (2)

Identification



BicIbanDir table

Bank Directory+ v3 file IBAN + v3 file

Ibankey - ISO COUNTRY CODE (6) + NATIONAL ID (9)

Bic BIC (15) if not set in IBAN+ file IBAN BIC (7)

RoutingBic - ROUTING BIC (8)

Chipsuid CHIPS UID (16) -

Subtype SUBTYPE INDICATOR (32) -

Address

Bankname INSTITUTION NAME (19) -

Branchname BRANCH INFORMATION (20) -

Addressl1 STREET ADDRESS 1 (22) -

Addressl2 STREET ADDRESS 2 (23) -

Addressl3 STREET ADDRESS 3 & 4 (24 & 25) -

City CITY (26) -

Zipcode ZIP CODE (28) -

Country COUNTRY NAME (29) -

Services SERVICE CODES (35) added to IBAN+ Services

SCT, SDB & SDC if SERVICE CONTEXT = "SEPA"

Dates


-

Expirationdate Updatedate + 50 years -

Banque de France FGDThe Banque de France FGD file is equivalent to the BIC + IBAN directory but limited to institutions situated in France (or French territories) and Monaco.

l The file contains records for banks and branches. There is an inner relationship between branches and banks that is resolved during import.



l The structure of a full file and a delta file are different.

The corresponding filename prefix is FGD. For details, see Importing and updating reference data on page 94.

Banque de France provides multiple FGD (France, Pacific and Monaco) files. The "Banque de France file compiler tool" enables you to compile and concatenate multiple FGD files into one single file that can be integrated directly inside Financial Standards Library.

For details, see Banque de France file compiler tool on page 111.

Bank recordsThese records all start with a '1'.

BicIbanDir table FGD (E records) file


RecordKey Code établissement (E2)

Identification

Ibankey Extract of BIC (E15) + Code établissement (E2) + "00000"

Bic BIC de l'établissement (E15)

RoutingBic -

Chipsuid -

Subtype -

Address

Bankname Dénomination 40 caractères (E4)

Branchname -

Addressl1 Adresse postale ligne 3 (E10)



City Extract from Adresse postale ligne 6 (E10) after ZIP Code

Zipcode Extract from Adresse postale ligne 6 (E10) First 5 characters

Country MONACO if COUNTRY_CODE = "MC". Otherwise FRANCE



BicIbanDir table FGD (E records) file

Services -

Dates

Updatedate Date of file or of import

Expirationdate Date de fin de diffusion (E9)

Branch recordsThese records all start with a '3'.

BicIbanDir table FGD (G records) file


RecordKey "3" + Code établissement (G2) + Code guichet (G3)

Identification

Ibankey Country extracted from BIC (G15) + (G2) + (G3)

Bic For branches, BIC is read in G15. If not set, the BIC of the parent bank is used.

RoutingBic BIC of branch indicated by G19

Chipsuid -

Subtype -

Address

Bankname Dénomination particulière (G5), or use (G2) if not specified

Branchname Nom du guichet (G6)

Addressl1 Adresse postale ligne 3 (G14)



City Extract from Adresse postale ligne 6 (G14) after ZIP Code

Zipcode Extract from Adresse postale ligne 6 (G14) First 5 characters



BicIbanDir table FGD (G records) file

Country MONACO if COUNTRY_CODE = "MC". Otherwise FRANCE

Services -

Dates


Expirationdate Date de fin de diffusion (G18)

Note For branches, BIC is read in G15. If not set, the BIC of the parent bank is used.

Bundesbank BLZ v1 and v2The BLZ format changed on 03 June 2013 from v1 to v2. Both versions are handled.

The corresponding filename prefix is BLZ. For details, see Supported Reference Data files on page 96.

BicIbanDir table BLZ file


RecordKey Record Number (10)

Identification

Ibankey "DE" + Bank Sort Code (1)

Bic BIC (8)

RoutingBic Routing BIC derived from Successor Bank Sort Code (13)

Chipsuid -

Subtype -

Address

Bankname Name (3)

Branchname

Addressl1

Addressl2



BicIbanDir table BLZ file

Addressl3

City Location (5)

Zipcode Postal Code (4)

Country "DEUTSCHLAND"

Services -

Dates


Expirationdate Updatedate + 50 years or Updatedate + 3 months if about to be deleted



Banque de France file compiler tool

OverviewThe Banque de France file compiler tool is designed to compile multiple FGD "situation" files into a single file that can be integrated directly inside Financial Standards Library reference data. The tool sorts the files, removes duplicates, and gives a summary of its actions.

After installation you can start this tool using the launch script located in:

<Installation_directory>/Financial_Standards_Library/bin.

l On UNIX the command is fgdcomp.sh

l On Windows the command is fgdcomp.bat

Usage./fgdcomp.sh <outfile> <infile1> ... <infileN>

l <outfile> is the name of the output file to generate (ready to import inside reference data).

l <infileX> is the name of a file to process and concatenate. There can be 1 to N files separated by a blank space.

Banque de France provides multiple FGD files instead of providing a single file with all information. It provides three files (France, Pacific and Monaco).

If you need information on banks in Monaco, you only need to import the Monaco file and do not require the Banque de France file compiler tool.

If you need France and Monaco, the Banque de France file compiler must be used to concatenate the France and Monaco files, in order to be able to import them.

Examples

Example 1: combine three files

./fgdcomp.sh FGD_OUT.TXT

FGD_SITUATION_SEPA_FRANCE_140318_1103.TXT

FGD_SITUATION_SEPA_MONACO_140318_1103.TXT

FGD_SITUATION_PACIFIQUE_140318_1103.TXT

The tool reads the three FGD_SITUATION files, concatenates them, removes duplicates and outputs the result to FGD_OUT.TXT.



Example 2: combine two files

./fgdcomp.sh FGD_SITUATION.TXT

FGD_SITUATION_SEPA_FRANCE_140318_1103.TXT

FGD_SITUATION_SEPA_MONACO_140318_1103.TXT

The tool reads the two FGD_SITUATION files, concatenates them, removes duplicates and outputs the result to FGD_SITUATION.TXT.



Analysis & migration tool

OverviewThe Integrator export file Analyzer is a tool that helps you analyze the custom function usage in Integrator/Composer.

It is designed to ease the migration of Composer objects from the older BIC-IBAN custom function set to the newer one (using the generic Reference Data).

It can also be used to migrate any custom function from an older version to a newer one, or from a folder to another (provided it is under the same root folder).

It analyzes the exported file contents and is able to give a view of where and how custom functions are used.

When the analysis is complete, it is possible to create a replacement configuration file and let the Analyzer replace custom functions with others.

The Analyzer can work on a single file, directory, or even on a whole directory structure.

Command line helpThe tool has a built-in command line help in GNU format.

xibanalyser -h (or --help) displays the following screen (under Windows):

usage: xibanalyser -f | -h | -r <arg> [-l <arg>] [-p <arg>] [-s] [-u]

[-x <arg>]

Integration process analyser 1.0

Finds Custom functions definition and usage and is able to replace

Custom functions by others

-f,--find find custom functions

-h,--help display this help

-l,--length <arg> maximum length of expressions and descriptions. If 0

-> don't truncate (default is 80)

-p,--path <arg> path to scan (directory or file)

-r,--replace <arg> replace custom functions (indicate replace

instructions file)

-s,--recurse recursive search through sub directories

-u,--usage display expressions in which functions are used

-x,--suffix <arg> suffix to add to the updated file names. (default is

"_new")



If you make an error in the command line, the detected error will be displayed followed by the command line help screen.

Analysis modeIn analysis mode, the Analyzer scans each file and reports custom function definitions and their usage.

Command linexibanalyser -f (or --find) starts the Analyzer in analysis mode.

The following options apply to an analysis:

-p <search path>: (mandatory) Indicates the path to analyze. This path can be a single file or a directory.

-s: If set, requests the exploring of subdirectories as well. This only applies if the search path is a directory.

-u: If set, the Analyzer displays the usage of the found custom functions in expressions.

-l <length>: If present, this option controls the display of the expression. It only applies if option –u is set. By default, the length is 80 chars, meaning that it will display an 80-character extract based on the appearance of the first custom function in the expression. If <length> is greater than 0, the extract has its EOL and TAB markers converted into spaces. If 0, the whole native expression (with EOL and TAB) is displayed.

Examplexibanalyser –f -p C:\Composer\lib\Maps -s -u -l 100

This launches the Analyzer requesting it to analyze every Composer file it finds under the C:\Composer\lib\Maps folder and sub-folders. It displays the expressions where each function is used, truncated to 100 characters.

Information outputBy default, the output is directed to the console but it is recommended to redirect it to a file for easy parsing.

The analysis output is divided into three parts:

l A list of all parsed files with a summary of the analysis of each: The number of functions found or errors. It is displayed in realtime to allow you to track the progress.

l A list of all custom functions found with detailed information on each, and in which files they appear.



l A summary indicating for each distinctly named custom function, how many times it is declared and used.

List of all parsed filesThe real-time display of the currently parsed file allows you to track the progress of the parsing process.

The parsing of a file can:

l Skip it if it is not an Integrator/Composer file.

l Produce an error if the file is an Integrator/Composer file, but cannot be read correctly.

l Give the number of custom functions found if it is a valid Integrator/Composer file.

Example

Analysing C:\Dev\Java\Integrator\lib and sub directories...

…

Parsing C:\Dev\Java\Integrator\lib\BDocs\EBAStep2\V2_

2\mpedddnfblkdirdeb.xml... ERROR: Invalid encoding name "UTF-8 ".

…

Parsing C:\Dev\Java\Integrator\lib\BDocs\Exception_Investigations\V1_

1\addpaymtinfov02.xml... found 2 function(s)

…

Parsing C:\Dev\Java\Integrator\lib\Maps\pom.xml... Not an Integrator

file

List of all found custom functionsOnce the parsing job is complete, the Analyzer displays all the different custom function definitions it found.

A custom function is distinctly defined by:

l A function name

l A function Id

l A directory

For each distinct custom function, the following information is displayed:

l Logical-name: Name of the custom function

l Label: Help label of the custom function

l Unique-id: Signature of the custom function

l Modification-folder: Folder where the custom function is declared

l Modification-user: Indicates who modified the function last

l Modification-date: Date of last modification



l Physical-name: Internal name

l Extern-lib-name: Java Class if the function is a Java function. Empty if it is a DML function.

l Method-name: Java method name if the function is a Java function. Empty if it is a DML function.

l Description: is the textual description of the function

l Parameters: gives the list of expected parameters (name and associated help label)

l Declaration locations: Indicates all the files where the custom function is declared. It optionally shows the expressions where it is used (extract or whole expression depending on option –u)

All labels correspond to the XML tags as they appear in the XML.

Custom function:

* logical-name: CFpattern

* label:

* unique-id: 64b13a40-633f-11df-b4c9-005056c00008

* modification-folder: Solution\COMMON_OBJECTS

* modification-user: ADMIN

* modification-date: 2010-05-19T17:39:34.000+05:30

* physical-name: 64b13a3f-633f-11df-b4c9-005056c00008

* extern-lib-name: RegexpAnalyser

* method-name: analyzeRegexp

* description:

* parameters:

- pattern: pattern

- value: value Declaration locations: 3

* C:\Dev\Java\Integrator\lib\BDocs\CashManagement\V4_0\adlpymtinfo.xml

(2)

- expression: "...f not(\COMMON_OBJECTS.CFpattern("CH[0-9]

{6}",this))then { addTrace("WARNING", "not following t..."

- expression: "...f not(\COMMON_OBJECTS.CFpattern("[a-zA-Z0-9]

{1,30}",this))then { addTrace("WARNING", "not foll..."

* C:\Dev\Java\Integrator\lib\BDocs\CashReporting\V5_0\acctrepreqv01.xml

(1)

- expression: "...f not(\COMMON_OBJECTS.CFpattern("[\\+][0-9]{1,3}-

[0-9()+\\-]{1,30}",this))then { addTrace("WAR..." *

C:\Dev\Java\Integrator\lib\BDocs\TradeServicesInitiation\2007\invcfincgc

xlreqv01.xml (2)

- expression: "...f not(\COMMON_OBJECTS.CFpattern("CH[0-9]

{6,6}",this\USCHU))then { addTrace("WARNING", "not fol..."

- expression: "...f not(\COMMON_OBJECTS.CFpattern("ZA[0-9]

{6,6}",this\ZANCC))then { addTrace("WARNING", "not fol..."



SummaryThe summary indicates for each distinct function name:

l The number of distinct definitions found

l The number of total declarations (number of files it has been found in)

l The number of distinct expressions that use it (for all definitions)

Below is a summary of the analysis of the whole set of mappings and BDocs. It shows that there are many different definitions of the same function:

Summary:

* CFpattern: 7 distinct definition(s), 49 usage declaration(s), found in

54 expressions

* Check_Digit: 1 distinct definition(s), 26 usage declaration(s), found

in 27 expressions

* GetBICForIBAN: 6 distinct definition(s), 19 usage declaration(s),

found in 33 expressions

* GetIBAN: 2 distinct definition(s), 11 usage declaration(s), found in

22 expressions

* GetNationalCodeForIBAN: 4 distinct definition(s), 8 usage declaration

(s), found in 8 expressions

* GetRIBKey: 2 distinct definition(s), 5 usage declaration(s), found in

10 expressions

* IsKeyPresentBIC: 9 distinct definition(s), 1462 usage declaration(s),


* SWCheck_BIC2: 7 distinct definition(s), 441 usage declaration(s),


Replacement modeIn replacement mode, the Analyzer replaces custom function definitions with others. To do so, it needs a replacement configuration file that tells it what to replace by what. This replacement configuration file is easy to create. See Replacement config file on page 118 for instructions. When a file is modified, the modified version is saved under a new name.

Command linexibanalyser -r <ConfigFile> (or –replace <ConfigFile>), launches the Analyzer in replacement mode.

The following options apply to a replacement:

-r <ConfigFile>: Indicates replacement mode and the name of the replacement configuration file to use.



-p <search path>: (mandatory) Indicates the path to analyze. This path can be a single file or a directory.

-s: If set, requests the exploring of subdirectories as well. This only applies if the search path is a directory

-u: If set, the Analyzer displays the usage of matching custom functions in expressions, before and after replacement

-l <length>: If present, this option controls the display of the expression. It only applies if option –u is set. By default, the length is 80 characters, meaning that it displays an 80-character extract centered on the first custom function appearance in the expression. If <length> is greater than 0, the extract has its EOL and TAB markers converted into spaces. If 0, the whole native expression (with EOL and TAB) is displayed. Here, as it is a replacement case, both before replacement and after replacement expressions take that size setting.

-x <suffix>: Controls the suffix of modified files. By default, it is _new. The suffix is added before the extension of the file (which is always .xml). Therefore, by default, if file.xml is changed, its new version will be saved under file_new.xml.

Examplexibanalyser –r replace.xml -p C:\Composer\lib -s -u -l 100 –x ""

This launches the Analyzer, and asks it to modify every Composer file it finds under the C:\Composer\lib folder and sub-folders that match the replacement configuration set in replace.xml (in current folder). Because the provided suffix is empty, the modified files will overwrite the original ones. The display will show the old and new expressions truncated to 100 characters each.

Replacement config fileThe replacement config file is an XML file similar to the Composer export file. It defines the replacement job to be executed.

It is organized as follows:

l The root tag is replace-config

l Each replacement (new) function complete definition is inserted under the tag objects-list.



l In each replacement function, the tag replaces contains the definitions of the old custom functions it replaces:

o Each old function definition is surrounded by the tag object-list

o The entire custom function definition can be inserted although only the following information is required for the replacement:

o Attribute unique-id

o Tag logical-name

o Tag modification-folder

Important: The root of the modification-folder must be the same for the function being replaced and its replacement.

For example:

l SWIFT\SWIFT_DATA modification folder cannot be changed into Solution\COMMON_OBJECTS

l Solution\Transformation\SCT_PSR\V2 modification folder can be changed into Solution\COMMON_OBJECTS

ExampleThe example configuration file below sets the replacement of two old IsKeyPresentBic custom function definitions with the new IsBicLCBCValid definition.

<?xml version="1.0" encoding="UTF-8"?>

<replace-config>

<objects-list xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

class-version="1.0" unique-id="6b86ac38-63e3-11e2-a4d1-005056c00008"

during-import="true" xsi:type="custom-function">

<replaces>

<objects-list xmlns:xsi="http://www.w3.org/2001/XMLSchema-

instance" class-version="1.0" unique-id="554a1ea8-ba00-11dd-94f2-

005056c00008" during-import="true" xsi:type="custom-function">

<logical-name>IsKeyPresentBIC</logical-name>

<modification-folder>Solution\SWIFT_DATA</modification-folder>

</objects-list>

<objects-list xmlns:xsi="http://www.w3.org/2001/XMLSchema-

instance" class-version="1.0" unique-id="1422e753-94fe-11df-9f01-

000c29691340" during-import="true" xsi:type="custom-function">

<logical-name>IsKeyPresentBIC</logical-name>

<modification-folder>Solution\COMMON_OBJECTS</modification-folder>

</objects-list>

</replaces>



<logical-name>IsBicLCBCValid</logical-name>

<label>Verifies if a BIC is a financial BIC (for compatibility)</label>

<creation-date>2013-01-21T16:58:32.000+01:00</creation-date>

<creation-user>EN</creation-user>

<creation-entity>Company</creation-entity>

<modification-date>2013-01-22T10:12:43.000+01:00</modification-date>

<modification-user>EN</modification-user>

<modification-entity>Company</modification-entity>

<modification-folder>Solution\COMMON_OBJECTS</modification-folder>

…

<d-mLExpression-list link-type="23" empty="true">

<name/>

</d-mLExpression-list>

</objects-list>

</replace-config>

Information outputBy default, the output is directed to the console but it is recommended to redirect it to a file for easy parsing.

The analysis output is divided into 4 parts:

l Replacement configuration indicating what will be done.

l List of all parsed files with a summary on the analysis of each: a replacement action report or error.

l List of all old Custom functions indicating for each distinctly named custom function, how many times it is declared and used.

l Summary indicating for each distinctly named custom function, how many times it is declared and used. (Same as in analysis mode).

Replacement configurationThis shows which custom function will be replaced by which new custom function. All identification information is displayed.



List of all parsed filesThe real-time display of the currently parsed file allows you to track the progress of the parsing process.

The parsing of a file can:

l Skip it if it is not an Integrator/Composer file.

l Produce an error if the file is an Integrator/Composer file, but cannot be read correctly.

l Give the number of custom functions found and replaced if it is a valid Integrator/Composer file as well as the name of the replacement file.

Example

Analysing C:\Dev\Java\Integrator\lib and sub directories...

…

Parsing

C:\Dev\Java\Integrator\lib\BDocs\AccountManagement\2010\acctrptv01.xm

l... ERROR: Invalid byte 2 of 4-byte UTF-8 sequence.

…

Parsing C:\Dev\Java\Integrator\lib\BDocs\CashReporting\V4_

0\gettransactionv04.xml... did 14 change(s) for 2 function(s)... saved

to C:\Dev\Java\Integrator\lib\BDocs\CashReporting\V4_

0\gettransactionv04_new.xml

…

Parsing C:\Dev\Java\Integrator\lib\Maps\pom.xml... Not an Integrator

file

…

List of all custom functions programmed for replacementAfter the parsing job has been done, the Analyzer displays all the custom function definitions it found in the replacement configuration file that were set to be replaced.

For each distinct old custom function definition, the same information, as for an analysis, is displayed. See List of all found custom functions on page 115.

Declaration locations indicates all the files where the old custom function was found. It optionally shows the original expression extract and the modified expression extract (extract or entire expression depending on option –u)



ExampleIn the following example extract, the report indicates that the Check_Digit custom function was replaced by the new CheckDigit custom function in 26 files.

Custom function:

* logical-name: Check_Digit

* label: null

* unique-id: f054622c-81cf-11e0-ac74-000c29f7c135

* modification-folder: Solution\COMMON_OBJECTS

* modification-user: null

* modification-date: null

* physical-name: null

* extern-lib-name: null

* method-name: null

* description: null

* parameters:

Declaration locations: 26

* C:\Dev\Java\Integrator\lib\BDocs\Nacha\2007\bdoc_ack.xml (1)

- expression: "...0) then{ if (\COMMON_OBJECTS.Check_Digit

(padStringLeft(this\ACK_DETAIL\REC..." replaced by "...0) then{ if

(\COMMON_OBJECTS.CheckDigit(padStringLeft(this\ACK_DETAIL\RECE..."

* C:\Dev\Java\Integrator\lib\BDocs\Nacha\2007\bdoc_adv.xml (1)

- expression: "...is\ADV { if (\COMMON_OBJECTS.Check_Digit

(padStringLeft(this\ADV_DETAIL\REC..." replaced by "...is\ADV { if

(\COMMON_OBJECTS.CheckDigit(padStringLeft(this\ADV_DETAIL\RECE..."

SummaryThe same information is displayed as in Summary on page 117.


6 Financial components

This chapter describes the FEX components in Axway Financial Standards Library and how to configure them in B2Bi.

Introduction to XML Encryption/Decryption JMC on page 123

Configuration on B2Bi on page 123

Register JMC on B2Bi on page 124

Introduction to XML Encryption/Decryption JMC

The Encryption/Decryption JMC is used to either encrypt or decrypt a file depending on the specified option.

This JMC has the following parameters:

operation:

Mandatory parameter.

Possible values:

l Encrypt: JMC will perform encryption on the files

l Decrypt: JMC will perform decryption on the files

Configuration file path:

Optional parameter.

The location of the xmlsec.properties configuration file. If no path is specified, the JMC uses the default file CORE_ROOT/config/xmlsec.properties.

Configuration on B2Bi

Prerequisites l Install B2Bi Server.

l Copy Financial Standards Library 3.9.0 from B2Bi Client to B2Bi Server.


6 Financial components

l Copy the file <B2Bi install dir>\Financial_Standards_Library\FEX_jmc\standardslibrary-xmlsecurity-1.0.0-1.zip and extract the files to this location: <B2Bi install dir>\Integrator\

l Register the JMC. For details, see Register JMC on B2Bi on page 124.

B2Bi UI configuration 1. Add the JMC as a component of type as "document" or "map".

2. Create a service of type Meta Data and add the above component.

3. Open the service created above and select the Configuration tab and add operation "Encrypt/Decrypt" accordingly.

4. Optional: Specify the Configuration file path, the path to xmlsec.properties, if you do not want to use the default one.

5. Select the Application delivery.

6. Create a Meta data profile and add the above-created metadata service to it. Use criteria Trading Engine: ConsumptionFileName equals <input filename>.

7. Place the input test file at Community Trading Pickup.

8. Verify the output for the selected operation (encryption or decryption).

Register JMC on B2Bi 1. To register the XML Security JMC:

a. Copy the JMC from <B2Bi install dir>\Financial_Standards_Library\FEX_jmc\standardslibrary-xmlsecurity-1.0.0-

2\java\components to <B2bSharedPath>\local\java\component

b. Copy the content from <B2Bi install dir>\Financial_Standards_Library\FEX_jmc\standardslibrary-xmlsecurity-1.0.0-

2\java\lib to <B2bSharedPath>\local\java\lib

2. Restart Integrator.

The JMCs will be auto-registered and will be available in the B2Bi UI, in a drop-down list.


Documents

5 February 2021 Administrator Guide