How can corporates and banks from non-EU countries cope with SEPA requests?

Sorina Bera, Allevo: If corporates become SEPA compliant, they will benefit of faster settlement and earlier access to a clear view on liquidity and cash flow.

SEPA has been a long debated subject in the financial sector almost for 10 years now. Although SEPA implementation in Euro countries is now considered a done deal, there still are holes and gaps that can be improved in non-euro members of the EU. On a paved road, now it is time for banks and corporates from non-euro countries to comply with this standard for processing payments requests. So, as of 31 October 2016, the SEPA end date, this regulation will have direct impact on non-euro countries in the EU/EEA. From that day on, transactions between banks and corporates must conform to the new European Standard in Financial Messaging.

The SEPA EU initiative aims to implement a uniform and competitive payment service which should translate into efficiency gains for businesses and public administrations, as well as for banks. Common standards, faster settlement and simplified processing are meant to improve cash flow, reduce costs and facilitate access to new markets.

What about this trio: SEPA, non-euro EU countries, corporate-to-bank space?

Via the EU Regulation No. 260/2012 for the corporate-to-bank space, SEPA sets the standard for processing payments requests: corporate customers must use ISO20022 pain.001 messages when requesting initiation of payments from their banks.

If corporates become SEPA compliant, they will benefit of faster settlement and earlier access to a clear view on liquidity and cash flow. So far, there are still corporates that have not planned for this project at all, while others are looking into options, planning or already implementing a solution to become compliant.

For corporates, the main requirement, as Europe moves towards a Single Euro Payments Area (SEPA), is to format their payments messages according to the existing SEPA schemes.

From recent experience of implementing SEPA in euro countries, it seems highly likely that the specifications will evolve, change and that they will keep on changing.

How to be ready for SEPA?

There are several phases for companies preparing for SEPA compliance: conduct an analysis on the impact of SEPA on internal processes and procedures, check if there are any internal applications ready to process congruent payment initiation or direct debit requests, establish an internal testing schedule and also plan testing sessions with partner banks. This means a lot of preparation and know-how are needed for the successful implementation of such a solution within a corporation. There are some steps that need to be taken in order to achieve it: impact analysis, defining requirements, updates/acquisition, implementation and testing.

Aside from the need to update all internal applications for conformity and given the tight SEPA compliance deadline, end of October 2016, Allevo’s recommendation consists of using a stand-alone converter application for translating current payment initiation requests into SEPA format. Such an approach considerably shortens the implementation time and also has no impact on internal applications and processes, while achieving rapid compliance and a more streamlined communication with the bank.

Allevo also provides a more complex and complete solution for corporations, a payment request centralization solution, a SEPA compliant solution that works irrespective of the format or standard used by running applications. Besides compliance, such a solution offers various benefits that include those that come with using a single window for all financial transactions sent or received from partner banks: filtering, validation, reporting, liquidity management, reconciliation, etc.

FinTP is Allevo’s complete open-source application that processes transactions, automates flows and offers compliance to regulatory and industry standards. In order to assist corporate customers in complying with the above-mentioned EU Regulation, Allevo created a specific SEPA feature for FinTP.

Being an open-source software, FinTP comes with several advantages: no initial licencing costs, unrestricted access to the application’s source code and technical documentation and full access to the resources of FINkers United, the community for all enthusiasts gathered around FinTP to rethink finance.

 

About Sorina Bera

Sorina Bera is the CEO of Allevo, a company focused on providing software solutions for various types of financial institutions. With a deep experience in technology, payments and SWIFT services, she joined Allevo in 2003 and three years later she promoted to lead the services team of the company. She has also been managing the relationships with Allevo’s customers and business partners.

Sorina brings extensive technology background, market sensitivity and vision. In her role as CEO, she was empowered to lead Allevo into its next phase and consolidate the change of the business model to open-source. The flagship software designed by Allevo’s specialists, FinTP, is the first application for processing financial transactions published under free open source licence.

 

About Allevo

Allevo provides software solutions that help financial institutions of all sizes reduce TCO and achieve end-to-end interoperability across the financial supply chain by using FinTP, a complete open-source application that processes transactions, automates flows and offers compliance to regulatory and industry standards.

The Allevo guaranteed distribution of FinTP is aimed to grow competitiveness and offer operational risk containment, making such systems affordable to SMEs as well.

FinTP and all ancillary documentation is distributed freely and openly through the FINkers United community and it provides collaboration ground for rapid development and integration of new technologies, such as crypto currencies, biometric security, data analysis algorithms. This creates an open infrastructure for achieving real-time payments and a better management of liquidity and assets.

 

 

Source: www.thepaypers.com

RedHat Summit 2016 opening plenary started with a powerful message delivered by   Jim Whitehurst, Red Hat’s president and CEO : helping communities innovate beyond the sum of their individual members is the leadership challenge of our time.

The speech focused on the 4th industrial revolution that is happening right now : billions of people and devices connected, unlimited access to knowledge, AI breakthroughs, 3D printing, all helping innovation happen at a greater than ever speed.

Our abilityto harness and distill the best ideas will determine human progress for the next century and open communities are in a unique position to drive this innovation : the next developments are too big even for the largest corporations to address alone. Companies are realizing there is more value in opening their platforms and creating ecosystems than staying closed and building systems.

A couple of weeks before the event I started scheduling the sessions that I would like to attend and decided to focus on three areas : open source communities development, devops and mobile.

Open source communities

Working with an open source project and delivering an enterprise product based on it poses some challenges to vendors.

How do we distribute changes ?

Some vendors maintain differentiation by developing features in private, and integrating them in their products, eventually integrating them into the upstream open source projects (if ever). Others will integrate changes at the same time as they are released in a product.

RedHat’s policy is “upstream first” – features are integrated into open source projects before integrating them into its product offerings.

The arguments for upstream patching are that it saves time and money and keeps communities alive.

How do we keep the projects alive ?

One of the best ways is to hire developers and involve them in the upstream open source projects. This signals involvement from the company and that the project will not be abandoned.

How do we keep everyone in touch ?

There are many aspects and departments involved in keeping an enterprise product and the upstream project running. Making sure everyone understands the business model and changes are communicated throughout the ecosystem is required, or it could potentially destroy the company if legal issues arise.

There are different resources available for everyone :

⁃ For management: open source events

⁃ For developers: linuxfests, devops days, meetups, local events

⁃ For legal: legal networks, scale, fosdem, linuxcon

DevOps – we’re not IT anymore, we’re part of business

DevOps is an approach to culture, automation, and platform design aimed to increase the speed and flexibility of delivering new products or services.

Every department has its own tools that automate its processes – Jenkins for continuous integration used by developers, scripts or configuration management apps for operations, unit test frameworks used by QA or communication tools used by everyone. DevOps aims to automate as much as possible from code to deployment on production servers, so companies can focus on what’s important : creating business value.

It all starts with a company culture centered on collaboration and openness. Lines that separate traditional departments in a software development company (devs, infrastructure, QA) are blurred, communication is encouraged and tools are shared.

Automation is the key to accelerate application delivery. Everything that can be automatized should be, with focus on what takes the most time.

In order to enable automation for all departments, a set of dynamic, programmable tools is  required.

RedHat offers Ansible as a simple, powerful, agentless platform for automation. It uses an automation language that is accessible to non developers and is quick to learn.

Everything from continuous integration, deployment, provisioning, managing systems or communication can be described and automatised in Ansible.

Ansible Tower is an enterprise feature developed by Redhat to provide a simple dashboard, a restful API and role based access control for Ansible.

An approach to implementing DevOps starts with asking the right questions:

–      What can we automate and in what order ?

–      What is taking the most time in the delivery process ?

–      Do individuals understand the value of their contribution to the business ?

–      What is the effort and the impact of every contribution ?

–      How happy are the developers ?

–      How can we reduce technical debt ?

Mobile

Increasing the speed of delivering new features requires new paradigms in application architecture : shifting from a monolithic tiered approach to a cloud based, microservices architecture.

Mobile is not a new domain, but maturity brings new challenges: multiple versions of your backend API running in parallel, low latency requirements as your user base is expanding, memory constraints and so on.

Microservices are applications that address a small and independent set of business features. They communicate with a each other via “dumb pipes” – HTTP calls to REST APIs or fast lightweight messaging. They are independently deployable, so dependencies are easy to maintain and can run multiple versions at a time.

Microservices are also gaining ground because they require little to no effort for provisioning and can scale very well.

Developing a small set of independent functions enables rapid iterations and a more fluid way to define requirements and manage change. That is sometimes called agile development.

The last piece of the puzzle is DevOps. Almost everything about developing microservices can be automated, from continuous integration, testing, staging to deployment on production servers.

All these things are not new and can be dismissed as an overhyped trend (just don’t call it SOA 2.0), but the combination enables fast mobile application development.

Author: Horia Beschea, Software Development Director at Allevo

We use cookies to deliver a cosy experience on our website.

The website is built over Wordpress and it uses plugins to display content as intended.

By accepting this notice, you consent to cookies on this device as per our Cookie Policy.

Some contents or functionalities here are not available due to your cookie preferences!

This happens because the functionality/content marked as “%SERVICE_NAME%” uses cookies kept disabled. To view this content or use this functionality, please enable cookies: click here to open your cookie preferences.