New hot-deploy application

[Pierre Smits]

Dear all,

SEPA (Single European Payments Area) is an initative of the European
banking industry that will make all electronic payments across the Euro
area  as easy as domestic electronic payments within one country are now.
This initiative encompasses credit card, debit card, bank transfer or
direct debit transactions.

More information regarding SEPA can be found here:
http://ec.europa.eu/internal_market/payments/sepa/

and at websites of the various banks in Europe.

We intend to start a project to build a new hot-deploy application that
enables/facilitate the processing of (some of the) payment transactions and
bank statements as per these SEPA guidelines and regulations of the EU in
OFBiz

It is our intention to have the application deliver following functionality:

   - Create, edit, update and expire Banking organisations
   - Create, edit, update and expire bank accounts for each party
   - Enable the processing of bank statements and bank statement
   transactions (both manually and automatically*)
   - Enable the generation of bulk bank transfers regarding
   supplier/creditor payments, expense and other payments
   - Enable the generation of bulk direct debit transactions

As we are starting with this project we invite you to participate in
requirements gathering and specification (both business and technical)  to
be able to define a reasonable scoping and planning of a first release.
If you are - or do business with customers (OFBiz users)  - in the EU
market space  and have knowledge regarding national or even bank specific
requirements and/or definitions and guidelines, please share. Your insights
are valuable and we appreciate your input.

Should you have any questions and/or remarks regarding this, please let me
know.

With regards

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

[Ted Byers]

That is exciting.  Am I to understand that that means that there will
be a single API for processing all these different kinds of
transactions, including credit and debit card transactions in
ecommerce?  Or are we still stuck with different APIs for different
processors?

One thing that is intriguing is that that page refers to a grants
program.  That may create an opportunity to improve fraud prevention
and gain financial support for developing and deploying it (I know of
one option that will make card absent transactions as safe as card
present transactions, for both merchant and consumer, but have yet to
find the right person within the banking industry in Canada to make it
happen - the caveat is it needs the cooperation of all members of the
credit card networks, and getting that cooperation may be a problem).

What do you know about their anti-fraud practices/recommendations?

Cheers

Ted

[Pierre Smits]

Hi Ted,

Thanks for your reply.

I will try to answer your questions as extensive and precise as possible
(given that I don't know everything there is to know regarding this
subject).

First of all, I don't believe it is feasible to come up with a solution
that enables all variations possible within a reasonable timeframe.
Secondly, in current setup several payment processing solutions are already
hard-wired in the accounting component. These payment processing solution
are provider specific, and as far as I know SEPA only defines Pan-EU
guidelines and regulations. EU nations have their own agendas and therefor
each bank in each country can - as influenced by their own legacy system -
deviate to some extend from the EU program and national programs.

I know for a fact that in The Netherlands the central bank is driving the
national program and the larger system banks differ from each other
 regarding their implementation projects.The only mandatory aspect is the
deadline of February 1st, 2014 to have SEPA solutions in place. Having done
a short rond of questions with a few Dutch banks I learned that these banks
do vary regarding the technical implementation.
I assume this is applicable regarding any other EU nation and bank in these
nations. That is why I am asking for sharing insights regarding these
per-country and bank differences.

As I already tried to outline in my initial email I plan to focus on a
feasible scope and plan regarding:
- IBAN Account definitions (IBAN - see this
link<http://en.wikipedia.org/wiki/International_Bank_Account_Number>)
and their association to parties
- SEPA Credit transfers (SCT - see this
link<http://www.europeanpaymentscouncil.eu/content.cfm?page=sepa_credit_transfer>)
regarding payment of purchase invoices, expenses and other payments related
to IBAN-
- SEPA Direct Debits (SDD - see this
link<http://www.europeanpaymentscouncil.eu/content.cfm?page=sepa_direct_debit_(sdd)>)
regarding payment of sales invoices related to IBAN

As for your remarks and question regarding the anti-fraud practices and/or
recommendations I don't have any insights to share. It hasn't been on my
mind yet.


With regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

[Paul Piper]

Hey Pierre,

first off all: Kudos! SEPA is certainly a hot topic at the moment.

So what in particular did you guys have in mind? In terms of payment-processes most should already be covered by the ePayment Providers - including SEPA transaction. So I am a bit curious to see where you are heading with this? Just adding the entity data to make it a seperate transaction type? Where does the application come in place?

I assume you are not working on a full hbci+ integration, correct?

Cheers,
Paul