When embarking on robo-advisor platform development, you want to make it efficient, successful, and free of setbacks. From my point of view, there are three main factors of success in software development:

  • Before you start development, you should have detailed documentation prepared, including software requirements specification, architecture description, etc.
  • To create the software, you need a good team with the correct set of skills, including business analysts, software developers, QA specialists, and so on.
  • To meet your time and cost estimates, your team should show good performance.

Here, I don’t want to go into the issue of documentation (which I considered in earlier posts). Instead, I’ll focus on the development team and its performance. Both of these issues are complex, so I want to discuss them in detail.

When you select a development team, it generally doesn’t matter whether the team is in-house or outsourced. Skills and experience play the most significant role when talking about developers. To implement a robo-advisor, coders that are only able to map your precise algorithm to code are unlikely to help you; conversely, developers with financial knowledge may enhance the process by reducing time and improving quality.

Reducing the Development Time

According to the Learning Curve, which was first described by psychologist Hermann Ebbinghaus, while teaching developers requires initial costs, it results in higher cost and time savings as their efficiency and productivity improves. However, when you have developers with a deep domain knowledge background, time for learning reduces significantly.

Learning Curve of Performance Value by Time
Fig. 1: Learning Curve of Performance Value by Time. (Source: LinkedIn)

To execute a robo-advisor platform, you need to describe tasks to developers. Due to the inherent system complexity and diversity of functionality, it may take a great deal of time to make a developer with no financial expertise comprehend what realized or unrealized gains and losses mean, how to measure portfolio risks, and which asset-allocation strategy should be used in a particular case. These are only few examples; for the platform, a multitude of such terms and algorithms should be programmed.

If developers lack understanding of terms and processes in wealth management, they will need to expend more effort on executing services that provide correct data processing and finding reasons for inaccurate or even incorrect output. The same worries concern QA specialists: without enough domain knowledge, they are unlikely to identify mistakes without adequate documentation.

According to our experience, developers that have financial knowledge and expertise have the following advantages:

  • Tasks are correctly understood after being explained once. On the other hand, developers without basic knowledge usually require explanations of the tasks and logics to be repeated three or four times.
  • If a service produces some incorrect results, knowledge in wealth management usually helps developers to quickly reveal and rectify mistakes in the mathematics or logics coded. On the contrary, without such knowledge, developers may not realize what mistakes have been made, and will spend much time checking their code.

Very often when discussing tasks, developers with general knowledge in finances and wealth ask many questions; by contrast, developers without such expertise don’t spend time seeking additional explanations. As a result, in the first case work is mostly done quicker and rarely requires any improvements; in the second case, the need for clarifications appears while coding. If developers lack the specific domain knowledge and do not seek clarifications, then significant additional time will need to be spent reworking and debugging.


You ask a developer to implement a microservice that will count unrealized gains of assets from the portfolio of a selected client. In this task, the developer encounters the following unknown terms: “portfolio,” “assets,” “unrealized gains.” To understand their meaning, he/she opens Investopedia and reads the following:

  • “A portfolio is a grouping of financial assets such as stocks, bonds, and cash equivalents, as well as their funds counterparts, including mutual, exchange-traded and closed funds.
  • An asset is a resource with economic value that an individual, corporation or country owns or controls with the expectation that it will provide future benefit.
  • An unrealized gain is a profit that exists on paper, resulting from an investment.”

These descriptions may not be helpful to the developer in starting the work. However, he/she may start to work quicker if he/she knows that:

  • A portfolio is a set of all financial assets held by a client.
  • An asset is an investment instrument that can be bought and sold.
  • An unrealized gain is the return of an asset, which is the percentage value increase from the time it was purchased to the time it may be sold (though it has not yet been sold). The formula to determine this value can be found in this post.

Once the developer understands the task, the work starts immediately. Otherwise, developers need time to find information, delve into it, and then start their work. In the series of blog posts, I plan to show how financial terms may be explained in language that is understandable to developers. From time to time, I will publish sets of terms that may be useful for developers of robo-advisor platforms.

Improving the Quality of Development

As the Learning Curve goes up, the developer’s performance improves and he/she increases in value. When hiring experienced developers, you can get high-quality work that will become even better as their experience broadens.

One of the most common problems that occurs when describing a task to a developer is that you omit facts that you perceive to be basic knowledge, but are in fact unknown to those outside the financial industry. Without this knowledge, developers will not be able to implement tasks correctly and you may not understand what is wrong with the software. In addition, when developers lack wealth management knowledge, they don’t anticipate the fact that under certain circumstances, logics may change.

To efficiently create a robo-advisor platform, you need developers who understand what it is supposed to do, and its logics and mathematics. I would even say that developers should know wealth management better than mid-level financial specialists. Unlike such specialists, who need to solve exceptional situations only on the rare occasions that they arise, robo-advisor developers need to explicitly work all such exceptions into the code before they actually happen.

If developers have no understanding of what they create, the software will reflect their vision of the solution but not the expected functionality.

In my opinion, the following knowledge is required for efficient software development of wealth-management platforms (these are presented in the order in which they are learned):

  1. Basic financial terms and concepts: assets, securities, returns, risks, interest rate, debt, etc.
  2. Financial and capital markets: optimal portfolio, asset allocation, diversification, etc.
  3. Financial engineering and risk management: arbitrage pricing, forwards, futures, swaps and options, credit-default swaps and defaultable bonds, mortgage-backed securities and the financial crisis, etc.
  4. Quantitative analysis: vocabulary and mathematical functions used for quantitative modeling, types of models (linear, probabilistic, regression models), simulation and optimization, etc.

However, responsible developers, even those with expertise and deep knowledge, always ask clarifying questions, and confirm every step of every process because they understand that:

  1. Theoretical knowledge and real business may significantly differ;
  2. In two different companies, even in the same industry, processes with similar names may involve different steps.

As a result, the software created by developers with domain knowledge contains fewer bugs and seldom requires essential rework. Based on my experience as CEO of a software company, when developers have domain knowledge and expertise, the number of bugs and the quantity of hours spent on rework decrease exponentially.

Rework VS Experience in Domain
Fig. 2: Rework VS Experience in Domain

I believe that Malcolm Gladwell’s “10,000-hour-rule” is close to reality: the more a developer works in the domain, the more domain knowledge he/she has gained and the higher quality the software will be in the end.

Experienced People in Robo-Advisory & Knowledge Transfer

It’s interesting to me how many C-level technical experts from existing robo-advisors have experience in wealth management. After looking at about 50 companies, I found that more than half of their leaders have several years of experience in WealthTech. Here are some names:

  • Christopher  Kingsbury, CTO at TradingScreen, has more than three years of financial experience working at Merrill Lynch.
  • Michael Tepp, Senior Developer and Team Lead at TradingScreen, also worked at Merrill Lynch for about three years. He has more than eight years’ total experience in leading financial companies, such as Barclays, JPMorgan, and UBS Investment Bank.
  • Dennis Sheckler, Chief Technologist at Vestmark, spent over 11 years at Thomson Financial.
  • Fritz Robbins, CTO at Personal Capital, started at Wells Fargo and has over five years of experience in banking industry.

You’ll learn more about my research in this regard from an infographic that I’ll be posting soon.

In our company, we have developed a concept of knowledge reuse that allows us to gain FinTech domain and solution knowledge in our Competency Center and transfer it to our developers.

FinTech Engineering Concept of Knowledge Reuse
Fig. 3: FinTech Engineering Concept of Knowledge Reuse


I’ve worked as a developer in the past, and am now CEO, so I understand the significant impact of developers’ industry knowledge on the quality of the software they create. Some of the facts that were mentioned above may seem obvious; however, unfortunately many companies do not consider them when arranging software development of robo-advisor platforms.

When creating a development team for your platform, the set of requirements should include both development skills and (at least general) knowledge of finance and wealth management. To ensure efficient development, the team should continually expand their knowledge about laws and regulations in wealth management, business functions of robo-advisors, interactions with other businesses in the financial industry and outside it, and so on. Such knowledge will help them to formulate truly insightful questions and obtain an exact understanding of what you expect them to create. As a result, you will achieve what you set out to do.

Moreover, with in-depth understanding of processes in wealth management, pro-active developers may sometimes suggest helpful ideas on how to enhance or simplify data processing, improve usability, or expand functionality.

In the following post, I will focus on how you can encourage your development team to improve their knowledge of wealth management, what methods are most efficient, and where to look for the knowledge.

How Can Your Acquisition Benefit From Keeping the Vendor?

How Can Your Acquisition Benefit From Keeping the Vendor?

Think of a vendor company as of a butler or a housekeeper. They spend years keeping the household running, know all the nooks and crannies in the house, the staff,…

Integration Challenges in Fintech: ETL Processing

Integration Challenges in Fintech: ETL Processing

For technology platforms, data is the lifeblood. Let me show you what challenges you might encounter when integrating data streams from financial institutions and taking control of the process.

Migrating WealthTech Platform to a New Framework

Migrating WealthTech Platform to a New Framework

Technology moves forward quickly, sweeping out whole ecosystems of tools and solutions and replacing them with new ones. Let us overview what pitfalls can one anticipate and avoid while migrating…

Employee Onboarding Gamified: Passing Stages to Productivity in WealthTech

Employee Onboarding Gamified: Passing Stages to Productivity in WealthTech

Streamlining the process of getting project knowledge and becoming prepared for productive work is the greatest benefit companies reap from onboarding gamification. Let’s assume that our onboarding is a game.

What Business Knowledge Training Sessions Do WealthTech Companies Have in Place?

What Business Knowledge Training Sessions Do WealthTech Companies Have in Place?

As the whole world goes remote, knowing how to motivate people distantly is a must for every company that wants to succeed. Read how teaching finance can help you motivate…

Can a Distributed Team Ruin a WealthTech Start-Up?

Can a Distributed Team Ruin a WealthTech Start-Up?

The market forces WealthTech transformation leaders to grow their business and scale teams. However, having a team that doesn’t fit your company can destroy everything you have built before. In…

Why Is It Important to Take into Account Vendors’ Previous Experience?

Why Is It Important to Take into Account Vendors’ Previous Experience?

Which is better—a team of highly skilled and experienced professionals or ambitious young people who compensate for little experience with enthusiasm? The answer to the question can be found only…

How FinTech Teaches Employees Personal Finance and Wins Their Engagement

How FinTech Teaches Employees Personal Finance and Wins Their Engagement

Conventional methods of studying the FinTech business domain tend to be boring. At INSART, we found a new method of engaging developers that helps them understand the needs of users,…