FinTech developer? 3 challenges and a case study

March 26, 2015 Neta Weinryb

If you manage the development of software solutions for financial institutions, this is the post for you.

Financial institutions are highly regulated and closely monitored.

As a result, software vendors that work with financial institutions are required to provide a well-managed and thoroughly documented solution. This affects development, release, deployment, and operations processes.

Open source components are an integral part of any software solution so the way you use them must also be carefully managed and reported.

Financial institutions follow regulations and directives that outline open source management requirements. Be it in the 2004 the Federal Financial Institutions Examination Council (FFIEC) "Risk Management for the Use of Free and Open Source Software" guidance, the FS-ISAC Product and Services Committee’s Whitepaper in the US or the up and coming EU directive on the subject, clear guidelines are offered for the management of the use of open source components.

These guidelines are applied by the financial institutions to the benchmarking and purchasing process of software. This presents FinTech software vendors with the following challenges:

  1. Financial institutions are encouraged to make sure that the open source components in the software they purchase and use are not stale. The FFIEC’s "Risk Management for the Use of Free and Open Source Software" guidance, for example, offers a list of criteria to help determine how popular and well maintained a component is.

You will be required to provide an open source report with every sale, and to provide information about the age (and sometimes popularity) of each open source component.

  1. Financial institutions are, of course, concerned about potential security issues in products they acquire. Recent security vulnerabilities in open source components (such as Heartbleed) raised awareness of open source components in commercial products. They want to know that this issue is well handled by their vendors.

You will be required to assure your customers that all the open source components in your software were updated to correct known bugs and security vulnerabilities.

We help you secure your open source components – download this guide to see how

  1. Financial Institutions are increasingly requiring their software suppliers to adhere to compliance and regulatory requirements. They cannot take the risk that their operations will be affected by a vendor entering a long legal process.

You will be required to provide an open source report with every sale, and to state that you comply with the requirements of the open source licenses that you use.

 

Sapiens, a leading global provider of software solutions for the insurance industry, with an emerging focus on the broader financial services sector, selected WhiteSource for management of its open source components. Since partnering with WhiteSource, Sapiens has freed key resources to concentrate on the company’s core business, lowered total cost of ownership and gained greater visibility. Sapiens can now provide its customers with detailed reports immediately, significantly improving the customer experience.

To see how Sapiens did all that, you can read our Sapiens case study.

 

 

Previous Article
3 Reasons Why Open Source Software is More Secure than Commercial Software. An Opinion.
3 Reasons Why Open Source Software is More Secure than Commercial Software. An Opinion.

The use of open source components is booming. According to analyst firms such as Forrester, Gartner, and 45...

Next Article
FinTech software developer? Top 4 open source management risks to avoid
FinTech software developer? Top 4 open source management risks to avoid

The FFIEC (Federal Financial Institutions Examination Council) has released the "Risk Management for the Us...