Facebook Twitter Linkedin
 

Blog

Archive for tag: banking

A newsletter for everyone?!

 

Survey

 

In a good-hearted intent to improve our newsletter and really make it a useful and informative tool for our readers, we have launched a survey. We asked them about their preferences and based on the fact that we were addressing quite a niche market, we underestimated how different people really are; and how different their individual interests are, even if they are working in the same field or industry.

 

Question 1: What areas are you most interested in: technology, banking, regulations, open source, events, corporations, business? We asked the respondents to give each category a rating from 1-not interested to 5-very interested.

The arithmetic mean was: Technology – 3.07, Banking – 4, Regulations – 3.37, Open Source – 3.11, Corporations – 3.22, Business – 4, Events – 3.07. Even though the differences are not so significant, we can see a slight inclination towards business, banking and the trends in this market rather than technology news.

 

Question 2: Are there other related areas you would like us to cover in our newsletter? What would those be?

In the accelerating pace of today’s world, open survey questions don’t seem to be very effective, with only 40.74% answering this question. Nevertheless, we had some suggestions like: projects developed, cloud industry, business and economic trends in the CEE states, impact of politic decisions on regulations.

 

Question 3: What type of information would you prefer to receive: news, analysis, how to’s, essays about personal experiences, etc? Check any that apply.

77.78% are interested in News, 62.96% in Analysis, 48.15% would like to receive how to’s and only 33.33% personal experience essays. As I said, the world is moving fast and it seems that people believe news helps us keep the pace.

 

Question 4: In which format would you like to receive our news? Article links you can access to read in full or a more integrated content with articles' synopsis/text previews/opinions.

This one is a tough one. How can you decide how to improve the structure of your newsletter when the answer to this question divided respondents almost 50-50? 55.56% said they prefer article links you can access to read in full, while the rest of 44.44% opted for a more integrated type of content.

 

Question 5: What news/information regarding Allevo would you like to receive on a monthly basis?

Product feature updates – 59.26%

New initiatives/projects – 88.89%

Updates on the BOOST- Banking On Open Source Technologies project – 37.04%

Opinion articles on market trends/news/events – 55.56%

Allevo events/workshops – 55.56%

 

Question 6: What news/information regarding the FinTP open source project and the FINkers United, the community around it, would you like to receive on a monthly basis?

New releases – 77.78%

New code updates on GitHub – 25.93%

New initiatives – 77.48%

FinTP events/hackathons – 40.74%

Other – 7.41%; included suggestions like howtos and new members or partners

Answers to questions 5 and 6 show people’s interest in what’s NEW. And although we are happy they are interested in our new projects in such a large proportion, the fact that our existing open source initiative rated low in interest in this survey raised a few questions: is open source not an interest priority in the banking world yet or BOOST is just not that well known or well explained?

 

Question 7: What would you change in the graphic format or the newsletter’s layout?

Open question, hence few answers. Most of the respondents said nothing, but there were some recommending a more appealing layout, less information, easier and friendlier navigation.

 

Question 8: If you have any other suggestions, we are more than happy to hear them.

Suggestions: less links, deliver the newsletter once every three months, provide a quick to read overview for included articles.

 

Lessons learned:

  • never underestimate people’s difference of opinions
  • you can never please everyone - but this does not stop us from trying
  • redesigning and restructuring our newsletter is not such an easy task


How to make the brave move from commercial to open source

 

by Mihai Guiman

 

FinTP code

I work for a private ISV and consultancy company focused on delivering software products for financial institutions. Three years ago my company decided to share our achievements and knowledge by publishing our application, FinTP, for processing financial transactions under an open source license.

Here, I will explore the changes a company has to undertake when embarking on the transition from a traditional business model to a business model that supports open source. This is based on nine years of experience with a once commercially-available solution. The motivation for a transition like this comes from our company's ambition to be in a position of leadership in this changing and challenging industry.

The culture of sharing in open source is our way forward, because we believe that by collaborating with the brainpower of an entire community of professionals that share the same values as us, we can deliver the best results. Recent studies on the financial industry say that by using open source, companies are able to collaboratively develop non-differentiating software for processing transactions or regulatory compliance, which is the plumbing and framework that all financial institutions need.

First, we selected the principles that would guide the team and chose an open source license. Then, we established the right kind of environment around the project by encouraging positive conditions for both for the current client base and for the potential community and user base. This helped us begin to attract contributors and adopters to the project.

Publishing our application as an open platform has impacted the core business and operational workflow of the company, thus drastic changes had to be made. The FinTP project and the community built around it had to receive more attention than the commercially available product because of the need to invest in developing and maintaining the project as well as actively integrating new members into the community.

Here's how we did it.

Adapt the proprietary solution

 

The requirements that an open source application has to satisfy are clear, but achieving them is thought-provoking. One of the most important changes than needs to be dealt with has to do with support for third party embedded products. Previously, only enterprise versions of prerequisites were supported so a rework was mandatory. The open source version supports the best open source alternatives for the enterprise database, message oriented middleware, and application server. All code included in the application must be compliant with the licensing requirements in order to be publishable. Also, open source alternatives for the internal developer tools, work item tracking, and source control systems have to be integrated.

In regards to product documentation and working procedure, the naming conventions, coding guidelines, and best practices implemented in the commercial version have to be adapted to address the specific needs of working within an open community. We found it necessary to include one more step in the preparation phase of publishing the product as open source: we shared FinTP on fintp.org, a platform with controlled access which allows us to fine-tune the community rules, processes, and product before posting it to an open source repository.

Build the open source community

 

When transitioning a closed-source product to an open source one, building a strong, vibrant community is the most important part. First, lets look at the differences between a closed community and an open one. An open community is comprised of reward-earning contributions made by anyone, from all community members. The code is open to inspection so anyone can fix problems, develop new features, and contribute code back, in a moderated form. For any given problem, there is the possibility of a large number of eyeballs viewing it. A closed community is comprised of the provider and the client base, and the maximum number of people looking at any given problem is always limited by the total number of employed developers.

In the early stages of our transition from a closed community to an open one, we were running a tight ship: we were the only ones responsible for keeping pace with the evolving standards of the financial industry, developing major new functionality, and reviewing contributed code. Over time, based on the value of contributions, new hierarchies emerged. Every member has these advantages in our open source community: the power to influence projects, attract and retain development talent, reduce development and maintenance cost.


Change the business model

 

A traditional business model is based on revenue through selling software licenses, maintenance fees, and professional services. This is disrupted when the decision is made to publish the main product as free and open source. We had the opportunity to benefit from a year-long consultancy program for FinTP, co-financed by a prestige International Financing Institution.

For the business, the goal was to establish a new business model and workflows, adapt internal processes, adapt organizational structure. For the community, the goal was to propose a governance structure, with legal aspects, working processes, and marketing materials.

The FinTP project is now setup to provide these building blocks for processing financial transactions for banks, corporations, public administrations, and micro-financing institutions:

  1. Help consolidate business work flows
  2. Create flexible interfaces for various market infrastructures
  3. Process various kinds of funds transfers (such as credit transfer, direct debit, debit instruments, treasury flows) while providing safe operations and duplicate detection
  4. Gain several operation functionalities (such as liquidity reporting, accounting reconciliation, AML transactions filtering, remittances management, and competitive reports)

Intertek ISO 9001:2008CMMI Level 2ISO  9001/2008 Dun & Bradstreet