Month: March 2014

As already known, as of 1 August 2014 (six months transitional period from 1 February 2014), bulk payments throughout Europe will have to be handled in accordance with the regulations for SEPA Credit Transfers and SEPA Direct Debits.

The Single Euro Payments Area (SEPA) refers to an economic area comprising well over 500 million citizens and some 20 million businesses and institutions. With SEPA, they are able now to pay all over extended Euro zone just as quickly, securely and conveniently as they do at national level .a either by a SEPA Credit Transfer or by a SEPA Direct Debit.

In the financial institution space SEPA schemas and ISO20022 are already known and widely implemented. But SEPA is not only about bank-to-bank transactions, corporates also have to comply. In fact looking back to the starting point of the SEPA initiative in 2004, SEPA was referring to the entire life-cycle from ordering customer to beneficiary:

“An area where citizens, companies and others will be able to make and receive payments in euro, within Europe, whether between or within national boundaries under the same basic conditions, rights and obligations, regardless of their location.” – European Payments Council Roadmap.

Having these facts on the table, the race to reach SEPA compliance is on, yet many companies/corporates have barely begun, never mind having fully SEPA-compliant payments in place, for corporate-to-bank connectivity.

Migrating to SEPA brings many different challenges for a corporate. Supporting the right data formats is one. Corporates need to check whether their systems are capable of processing the necessary SEPA formats (cash management – CAMT and payments initiation – PAIN messages).

Taking this into consideration and also over a decade expertise in payment processing landscape, Allevo can assist reaching the SEPA deadline, no matter if you are a corporate or a bank.

Allevo offer for SEPA compliance comprises the SEPAReady application for financial transaction processing and business & technical expertise. Looking only at the SEPA corporate-to-bank space, the application feature C2B ensures the processing of EUR payment initiation instructions compliant with SEPA rules and schemes, in the corporate-to-bank environment.

From solution’s point of view, C2B feature addresses separately the corporate-to-bank environment, offering 2 distinct applications: 1) for Corporates 2) for Banks.

1) C2B feature for Corporates ensures the processing of EUR payment initiation instructions for corporates, corresponding to the business flows in relation with their bank, in compliance with SEPA regulation and schemes.

C2B feature allows corporates to generate payments SEPA compliant. Payments will be delivered to the bank / Payment Service Providers (PSP’s) in the SEPA ISO20022 format (payment initiation messages – PAIN), enabling an easy interface of the corporate with the bank and offering advantages for both. Lower operating costs and simplified payments are just some of the advantages this solution provides for a corporate client.

Companies and institutions can use SEPA migration as an opportunity to optimize their cash and treasury management processes and structures.

2) C2B feature for Banks ensures the processing of Euro payment initiation instructions corresponding to the business flows in relation with their corporate clients.

C2B feature allows banks to receive SEPA compliant payment initiation requests from their corporate customers. The messages received are unpacked from the SEPA ISO20022 format in individual transactions and prepared to be processed by the bank’s Back Office applications.

From the bank’s point of view, C2B feature represents an easy way to implement a tool which ensures that the bank can receive SEPA compliant instructions from its corporate clients. C2B is increasing the efficiency of back office processes.

So far, good progress has been achieved with regard to creating SEPA awareness in the corporate sector, but for some companies, migration projects still must get under way and efforts must be intensified.

After 1 August 2014, there will be no further transitional period and everybody will have to use the SEPA standard, otherwise they risk refusal of transfers by payment service providers, who will have to refuse further processing of payments that are not delivered to them in the right technical format after the deadline applicable in the euro area.

Therefore, if you are a bank and you are SEPA compliant in relation with your correspondent banks or in relation with your CSM, but you cannot process SEPA instructions in relation with your corporate customers, there is a simple thing to do, just contact us and we will deliver exactly that component of our solution that you need, C2B Feature for Banks.

If you, as a bank, are fully SEPA compliant already (in relation with correspondent banks/CSM and your corporate clients), but some of your corporate clients are not ready for SEPA yet, you may help your customers by recommending our proven component C2B Feature for Corporates, which will help them become SEPA compliant in relation with their bank.

We are here to help you accommodate the market regulations and standards as fast and efficient as possible, so act now!

It’s been a while since I started to talk to people in the financial services ecosystem about our approach towards open source. At first, most of them thinking we were either bold, ahead of our time, or mad would listen to our story but would not really comment: “Let’s see where it goes” or “good luck with your brave intentions.” Only after we started to show progress with the delivery of the FinTP Project, did people start to look seriously at what we were doing. That’s when FinTP started to stir up interest and we got many inquiries about the project.

I’ve already shared the most common questions, like: Why do we do it? Why should we join?

It is also the time when skeptics started sharing their doubts on the success of the open source model, stating that the security vulnerabilities that come from community contributions are a barrier for the project’s reliability. Some were and still are even more pessimistic and claim that financial institutions cannot assume the potential risks that come with adopting an open source solution for critical parts of their business.

I am not going to fuel the ongoing debate on whether open source software is more secure than proprietary software, as it has already been discussed in detail with subjective arguments on both sides.

I have taken part both on delivering open source and closed source solutions. Both are subjected to the same security threats from a technical point of view. Each of the security vulnerabilities have to be contained through coherent management and control over the software development and deployment lifecycle processes. These processes need to be adapted to the type of distribution model—for open source and closed source. FinTP is in fact developed as the next version of a commercial closed source distributed product, for which application users and independent auditors haven’t been able identify any major security vulnerabilities. One of its strongest assets is the community of professionals who seek to contribute their experience and skills to improve the quality and design of FinTP.

This community is still being formed, thus our company still needs to ensure the mandatory alignment to regulations, technological improvements, and most of the bug fixing. We are the first, and for the time being, single source code creator for FinTP. While we expect the community to get traction and the space for collaboration to become more active, the natural trend is to transparently institutionalize the commitment process and committers role. Our company’s internal development and deployment processes went by the CMMI Level 3 process model and later on was adapted to a more Agile approach. By ensuring these processes are adapted to make sense and work in an open environment, I believe FinTP will succeed in maintaining at least the same quality standard. Having said that, I would like to add that in my opinion vulnerabilities that come from community contributions have a risk score as low as contributions in closed source applications.

I want to highlight a couple of areas regarding software security that we focused on while developing the FinTP Project, which should also be common for closed source projects.

According to White Source, most software applications embed open source libraries that are outdated. This means that an old release of a component, with known security issues or bugs, is included in an up-to-date version of the software, which you are using and counting on it to work flawless. Does anyone know if their software vendor embeds the latest versions of open source libraries in the enterprise applications delivered (or even which open source libraries are being used)? Open source applications are more transparent in displaying what technology is used, what the update policy is, and all related licensing implications. Moreover, having the project available in open source means that a neat open source policy is in place that can be checked anytime and in a regulated manner whether the latest versions of embedded open source libraries are included or not (or at least for the more sensitive ones).

The Open Web Application Security Project (OWASP) is an organization focused on improving the security of software, creating awareness, and laying a foundation for developing the security layer of software applications. Our teams of developers and testers established a methodology of assessing risk for security vulnerabilities, following the OWASP Enterprise Security API. That means the design of FinTP addresses the most common vulnerabilities and security best practices, covering a range of risk scores from low (passwords policy, bypassing authentication, and authorization schemas), to medium (credentials transport over an encrypted channel and confidential data encryption), to critical (StoredCross Site Scripting, SQL Injection, and Privilege escalation).

I want to stress that many security vulnerabilities occur and are exploited when technology is not properly understood and exploited. For closed source solutions, customers rely on the guarantees received from the manufacturer of the software or hardware and the provider of services. Usually, there are licensing agreements, maintenance contracts, and Service Level Agreements (SLA) which set a clear limitation of responsibilities between all parties involved. Two typical cases arise here. One is customers with limited resources rely on the skills and know-how of their suppliers. The other is when customers prefer to have control over selecting, deploying, and managing their platforms. When implementing open source solutions, the scenario repeats up to a point: some prefer to subcontract professional services (analysis, development, configuration, testing, deployment, and maintenance) when deploying a solution tailored for their specific needs, while others prefer to do everything in-house.

The difference when implementing an open source application comes from the activities that must be performed to ensure a successful deployment. There are many unstable versions released in open source projects, so choosing a stable baseline is very important. Also, testing for a specific configuration has to be done thoroughly and cannot be limited only to User Acceptance Tests. Another important task is to define an upgrade policy for your deployed open source solution, which is not a very easy thing to do. On one hand, custom developments and configurations have to be aligned to the community version of the application, and security vulnerabilities must be detected and fixed by the community. On the other hand, you want to have a predictable technological upgrade plan with as little maintenance effort and risk possible.

Enthusiasm and creativity are usually important drivers for any technological project, but successful completion always depends on proper management and control processes over the lifecycle of the project.

Our article was also published on opensource.com.