FINkers United for Dummies

Monday, March 24, 2014


First time I saw a “for Dummies” brochure, I found the expression a bit offensive. Even now, I thought twice whether to name this text “for Dummies” or “FINkers United ABCs”. But reading that first brochure I understood the value of it: having things explained, plain and simple, common language, without all the metaphors or exaggerated sales propaganda; having a concise, straight answer to the questions that can pop-up in anybody’s mind.

So that’s what I want do for FINkers United.


Chapter 1: General Aspects

What is FINkers United?

FINkers United® is an open source community for all financial thinkers’ enthusiasts – from IT developers to financial experts – gathered around the FinTP® Project.

PS: this also answers another question: where does the name come from? Well, from financial thinkers united.

What is FinTP?

FinTP is an open source financial transactions processing application meant to be used as an open platform in a strictly regulated market.

FinTP aims to push financial transactions interoperability forward – from the current message syntax standard layer towards transactions interpretation – thus attaining a higher semantic standardization layer.

What is the purpose of this community?

It’s to encourage creativity in the financial industry, to create an environment where ideas are seeded and brought to ripeness to the benefit of all. It is aimed at freeing people’s creativity and brains from reinventing the wheel, as it happens in a closed traditional environment, and allowing them to take advantage of all the benefits an open approach brings.

In fewer words, it aims to grow the FinTP application that Allevo has provided the code for through contributions at any level, from requirements to be implemented to various operating systems compatibility, support applications and so on.

Who can become a member?

Anyone who has an interest in this area, likes the idea, is passionate about developing in open source or is keen in taking part in building an innovative product may become a member. All you need to do is register on Actually, there is no community if it does not have purpose and this is given by its members.

All of you are welcome to our community, to use our code, to praise or criticize us, and give us feedback. Users who continue to engage with the project and its community will often become more and more involved. Such users may find themselves becoming contributors.

What is a contributor?

Contributors are community members who wish to take part in concrete ways in the community running. Their contributions can take many forms, but all are to be submitted as patches that should be validated by committers or project maintainers.

The types of contributors are detailed in Chapter 2: Structures and roles, together with how you can contribute, how your role can grow in the community and what’s higher up the chain.

If I do not have technical skills, could I still be part of it?

But of course you can. Any idea is welcome and any member’s knowledge is valuable to the community. For example, you might have an idea of a feature or new project you think is useful and worth adding over FinTP.

You can also contribute by sharing your expertise in discussions on the Forum, the designated space for all debates within the community. All contributions will be acknowledged and thanked for.

Oh, but where can I find the code?

We used the GitHub portal as the repository for the FinTP source code. But you can also find the binaries on the community’s web page,

It sounds interesting. Where can I read more about this?

On, the community’s portal. You can read about governance, structure and roles, meritocracy, voting, code of conduct and so on. And there are a lot of topics that might interest you on the forum.

Stay tuned for the following chapters of FINkers United for Dummies. We will explain the structure of the community, how exactly you can contribute, the roles you can have and of course, how the community really works, in terms of processes, activities and teamwork.



By Ioana Moldovan, 24 March 2014.



by Andrei Dutescu


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!

Thursday, March 20, 2014

by Mihai Guiman


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


FinTP testimonials – episode 5: please listen to Ruud van der Horst, independent consultant, talk about the way Allevo grew qPayIntegrator into FinTP.

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

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

By Ioana Moldovan, 19 March 2014.

Tuesday, March 18, 2014


by Alina Enache

The business relationship between Allevo and SWIFT started in 1999 when Allevo became a SWIFT Registered Vendor and continued over the years, going deeper into certifying Allevo’s employees and applications, thus becoming SWIFTReady Services Partner (starting 2003). Allevo’s services portfolio has gained SWIFT appreciation due to the large area of business competencies covered by our business experts (SWIFT certified consultants for TARGET2, SEPA, Cash Reporting, Securities, TSU, Corporate and EUCLID), as well as by our implementation & support engineers (certified for all the products available in SWIFTAlliance suite). Moreover, qPayIntegrator v2.0 was the first SWIFTReady SEPA certified solution (in 2008 and 2009), and at the same time, the first Romanian banking solution designed for payment systems, which obtains SWIFT’s recognition for its proven compliance with the banking industry standards. qPayIntegrator has also received the letter of conformity for successfully passing the technical and functional validation criteria within SWIFT’s certification programme for Workers’ Remmitances in 2010, renewed for SWIFTRemit 2.0 in 2012.

In 2009, Allevo has signed a SWIFT Agency Agreement covering the promotion of SWIFT Alliance suite and other SWIFT business solutions, as well as the delivery of the related services in Romania. This already tight business relationship was further enhanced in 2013 when Allevo was selected as SWIFT Business Partner for Romania. In this new role, Allevo intermediates and promotes not only the interfaces and messaging solutions provided by SWIFT, but also the business solutions dedicated to the operational areas in the banks or corporates that are connected to SWIFT, covering the Romanian territory.

As a SWIFT Business Partner, Allevo’s team dedicated to coordinating on behalf of SWIFT the activities for Romania is planning a series of campaigns, adapting to the local trends and needs of the Romanian community SWIFT ’s global promotion of its solutions and informing about the updates, enhancements or newly-launched products and services. Please find below a schedule for approaching SWIFT’s Romanian customers, as well as institutions not yet connected to SWIFT, on the following topics:

  • March 2014: BIC Directory (the SWIFTRef file that can be downloaded and used in any back-office/payments application for SWIFT messages validation and for updating the information about the banking correspondents) and Bankers World Online, an online platform giving access to all worldwide payments reference data available in the SWIFTRef utility (comprising financial information, correspondent banking data and contacts, credit risk ratings, all BIC codes from ISO-registry (200+ countries) from connected and non-connected financial institutions and corporates, all SEPA data, including IBAN/BIC validation and payments routing information, market infrastructures, etc).
  • April 2014: Accord for Treasury, a solution enabling real-time matching and exception handling for foreign exchange, money market, OTC derivatives, and commodity trade confirmations. It is a cloud-based solution that avoids any upfront infrastructure investment that can be easily accessed and used to maximize operator efficiency whilst minimizing costs and operational risk in the treasury – back office departments.
  • April 2014: SEPA Plus, a SWIFT reference data service providing the data needed to validate SEPA payment messages, as well as the information required for accurate and efficient routing (bank codes and their IBAN suitability to enable IBAN validation, SEPA specific BIC codes to enable completion of the BIC from the IBAN, SEPA routing information: Automated Clearing Houses membership and reachability, SEPA Credit Transfer and SEPA Direct Debit adherence to the SEPA schemes, etc).
  • May 2014: SWIFT for Corporates – a solution that enables corporates to exchange financial information (payments, securities orders, reporting) with all their financial institutions through one highly secure, standardized communication platform, as opposed to multiple connections, consequently providing more visibility of cash, less cost to manage transactions and improved security and reliability.
  • June 2014: Sanctions Screening – a cloud based solution hosted by SWIFT, that provides cost-effective screening of SWIFT messages in real time. SWIFT’s role at the heart of the international financial system enables transactions screening against multiple lists (managed and updated by SWIFT), allowing financial institutions to comply with sanctions laws, by blocking or flagging prohibited transactions in real-time. Being a cloud based solution, Sanctions Screening has no impact on the infrastructure and implies no software to install, making it less expensive than implementing an in-house system.
  • June 2014: approaching non-banking institutions active in the financial industry – for those institutions that are interested in exchanging all types of SWIFT messages and file with financial institutions worldwide via a secure, reliable and standardized channel, SWIFT offers Alliance Lite 2, a cloud-based connection to the SWIFT network and related applications and services. With no infrastructure to maintain and minimal upfront investment (usage-based monthly fee), Alliance Lite 2 provides increased automation and straight-through processing of the financial flows.

Given Allevo’s expertise in SWIFT solutions and experience in providing SWIFT professional services, our team expresses its availability to assist the Romanian community of banks, other financial institutions, financial infrastructures and corporates in any SWIFT-related matter.


By Ioana Moldovan, 18 March 2014.

As a SWIFT Business Partner, Allevo’s team, dedicated to coordinating on behalf of SWIFT the activities for Romania, is planning a series of campaigns, adapting SWIFT ’s global promotion of its solutions to the local trends and needs of the Romanian community and informing about the updates, enhancements or newly-launched products and services.


FinTP testimonials – episode 4: it’s Matteo Rizzi’s, General Partner SBT Venture Capital, turn to share his ideas on the FinTP project and how it addresses the agility and affordability issues.

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

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

By Ioana Moldovan, 05 March 2014.

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.