Credit transfer migration (flat format conversion to an XML file) is normally simple as only one scheme is defined (CORE scheme - basic service) but following points need to be handled with
- pain.001 version to be implemented: 2 versions are in general supported by the banks, 2006 and 2009 versions, but a third version is coming soon: "future" 2012 version.
- Payment products of the banks: some banks propose a lot of payment products (salary, suppliers, taxes...) that must be implemented if needed in the SEPA environment, the associated XML
message can differ from one bank to the other.
- Bank implementation of SEPA: most implementations are closed but differ on some points (some wants the company to be identified through a specific code, some requires optional tags...).
All these issues are just handled by a simple parameter customization. The enterprise has just to discuss with its bank the way to migrate. SEPA_NDAT adds no
constraint. All the payment files will be converted. In the latest version, the parameters can be automatically updated.
Note: For the credit transfer conversion, SEPA_NDAT could be delivered with a no limit license but this point must be discussed case per case (the kernel having been
developed to support batches of several millions of transactions).
The migration of direct debits needs to take care of following points:
- Different data, notions and responsibilities: the mandate is quite similar to the actual one but the related data differ and the way to handle those data is also different, futhermore the
creditor responsabilities are greater in the SEPA world.
- Presence of two types of mandate: the recurrent and the one-off mandate. The one-off can be used only once and the recurrent one needs to follow a specific life cycle (using the sequence type)
and respect specific delay regarding the sequence type used.
- Several operational schemes : CORE for basic services and B2B (business to business where specific rules apply) and in some countries COR1 where delays differ.
The way to define and use a mandate depends on the activity of the company, the number of products and the way the debtor will be debited. Two kinds of enterprises can be defined :
- Those having only one product or wanting to debit all their products and services once
- Those wanting to keep a debit per product or service.
The SEPA logic is the second one. The use of the first one is just a risk for the company: in case of the mandate revocation, all the recoveries will be blocked, treasury will be impacted and
additional cost to recover amounts will be needed.
The SEPA project is not limited to the migration of existing contracts. The enterprise has also to define the way to support new customers: old procedures until next February and/or the use of the
new procedures based on native SEPA requirements.
Using SEPA_NDAT simplifies the migration to SEPA but some changes have to be planned:
- In the first case described above, the relation between the creditor and the debtor account is a 1-1 type, the account is sufficient to recover the amounts
- The migration is immediate BUT the case of the debtor account change must be correctly handled:
- The simplest way is to amend the SEPA_NDAT definition without changing customer account within the payment flow,
- The proper way is to enrich the relation information with a unique ID that will be used when the payment flows will contain this ID
- If the payment flows can contain this unique ID from the start, any debtor change will be easier to handle.
- In the second case, the enterprise must attached a unique ID to each mandate (SEPA_NDAT supports the mandate ID as unique ID BUT it is better to define a neutral reference as a
contact ID) and then put in place 2 changes:
- Payment flows change to add the unique ID in each order
- SEPA_NDAT feed to initialize and then update the relation base before the related payment processing.
The use of this unique ID is the key to correctly handle direct debits migration.
With or without this applicaiton, the enterprise has to collect or handle the following points with its banks:
- get its new SEPA creditor ID (when direct debit issuer)
- get/understand the new payment products to be managed and impacts with today
- identify the flow ISO version to be implemented (and the bank strategy about the new and old one) and their related specificities
- organize the migration phases
- check the test capacities of its banks.
If the enterprise has a specific communication application, a new version of this software will certainly be needed to support XML formats.