News

For associations and SME, SEPA_NDAT (version 2.1) now allows the generation of SEPA payment files in a very simple way with very few data using Excel or csv files.

A SEPA credit transfer or a direct debit can be created from 3 data (the client ID or mandate ID for DD, the amount and the remittance information) when using a client definition file, if not, at least 2 additional data are required : the counterparty account and then counterparty name.

To lower the license prices and facilitate companies to migrate to SEPA and satisfy their obligations, the SEPA_NDAT product is now commerclialized differently:

• a license for credit transfers, a license for direct debits
• a "closed" licence vs an opened license where all parameters are accessible

The "closed" license mostly suits the banks for their own clients or mono bank companies.

The new functionnalities of version 2 :

• Support of non reachable credit transfert in the input files
• the same input file can hold CORE, B2B direct debits.

This Club is mostly a French group even if some European companies are part of it: Sentenial, Atos

Web site: www.clubsepa.eu/

This SEPA_NDAT product has been launched in May 2013 to help companies jump in the SEPA world with little or no change in their current applications. This will allow them to focus on the financial and organisational impacts of the new regulation by handling all technical aspects, including error handling and accounting reconciliation.

Discover this product through its global description or through one of its main functions:

• File conversion
• Relation database
• Error handling
• Accounting follow-up

The French version of the website is online and describes the SEPA_NDAT product.

The English version and other products' description will be available in late May.

Using the test generator (SEPA_TGEN), test files of one million SDD transactions have been created for a French bank to measure the impacts of huge batches on channels and payment engines.

To validate the flat file definition and reconciliation mechanism, four different flat file formats (the SCT and SDD formats for the customer side and their corresponding formats in the interbank space) have been implemented for a French bank using different payment applications.

The End-to-End reconciliation mechanism has been tested with success by comparing these generated flat files to the original data used within the injected pain files.

Responding to an international bank's needs, we have studied and implemented the EBA presettlement report generation by processing all outward and inward pacs files, this report being needed for their payment engine End of Day process.