Scaling WealthTech Company Growth Using a FinTech Engineering Approach

Vasyl Soloshchuk

The WealthTech industry is still young, but most WealthTech companies have reached the stage at which their business model has been validated, their minimum viable product (MVP) is successful, and venture capitalists are ready to invest if the company proves its ability to scale the business—that is, to achieve exponential growth. At this point, software, which is the backbone of WealthTech companies, can experience the following bottlenecks that prevent scaling:

  1. Inability to develop new features quickly due to a significant technical debt after early startup stages.
  2. Inability to scale the team due to a lack of established processes and team structure.
  3. Waste of effort due to miscommunication caused by a lack of business domain knowledge.

To resolve these key pains for our clients at INSART, we have introduced the FinTech Engineering Approach, a mix of proven practices in software architecture design, processes, team structure establishment, and training of engineers in the wealth-management business domain.

Bottleneck 1: Inability to develop new features quickly

During the early stages, the first goal of WealthTech companies is to validate their business model with an MVP. This is why software development is often provided in a very timely manner and many software concepts are simplified. Later, this gives rise to a technical debt including monolithic architecture, poorly documented code, performance issues, etc. However, the software team understands that refactoring and even reengineering will be required at the growth stage when the business starts to become successful.

As the business grows and gains popularity, a great number of new software features based on client feedback often need to be added quickly. Considering that monolithic software contains a rather complex codebase, the following challenges appear:

  • Development is protracted due to a great deal of testing required after each change made.
  • Software engineers that are new to the team need to understand the entire architecture before they are able to provide software development.
  • Software development cannot be parallelized due to a tangled codebase.

Shifting to a microservices approach is one solution to speed up software development in the long run. The following major steps should be followed:

  1. Split out small parts of the monolith into microservices to enable their further development independently of each other and the core system.
  2. Build new features as separate microservices.
  3. Provide communication between microservices and with the core system by means of APIs.
  4. Ensure each microservice is well documented to facilitate their use by other software engineers.

Let’s look at a specific example in which microservices architecture can help. A WealthTech company is developing a robo-advising system. It is in its early stages, and may not need a big data processing framework. But with a growing number of clients, the volume of financial market data is also growing exponentially. This data is gathered from multiple sources and includes end-of-day prices, bid and ask quotes, split ratios, account data, etc. The efficiency of the robo-advisory system depends on the number of securities covered (scope) and the historical depth (number of years) of data processed.

Monolithic Architecture Microservices Architecture
When adding a new data source, the entire system has to be tested. New microservices are created. Each gathers and extracts data from a separate new data source and stores it in the unified format in a database. The work of the microservice doesn’t influence other components of the system.
Every component using the data from the new source should be changed; processing capabilities for new data types should be added. Each component communicates with the database via API and receives data from different sources in the unified format.
When a new software engineer adds extracted data from the new data source, he/she may damage the system or the database. A new software engineer works separately and cannot affect the system or the database. Before including the microservice in the system, it may be checked by a more experienced engineer.

The system monolith vs. microservices architecture is not the only technical aspect impacting the ability to scale software development. Among others, I would highlight the following:

  • human-controlled process vs. 100% service orchestration (Docker, Kubernetes);
  • uncontrolled failures vs. fault-tolerant process (no single point of failure);
  • low performance and bottlenecks vs. high-performance clustering computation (Spark batch processing);
  • log files vs. transparent process analytics and monitoring (Nexus, Grafana, Kibana, etc.).

Bottleneck 2: Inability to scale the team

Microservices architecture allows WealthTech companies to speed up software development by parallelizing the work on different components. Each microservice (or group of microservices) may be built by a software engineer (or team of engineers) loosely coupled with other parts of the system. The company may hire any required number of software engineers and doesn’t need to give each of them numerous details on the system architecture—the engineer only needs to know the parameters of APIs to connect to other microservices.

However, at this stage new obstacles appear. If the development team is small enough the entire process might be quite simple; the company discusses its requirements and distributes responsibilities, and development starts. As the team expands, especially if remote software engineers are hired, software development management becomes more and more difficult if there are no established project management processes and a structured team with specific roles in place.

For example, financial advisors, as prospective clients of robo-advisory systems, work with various CRM software, such as Wealthbox CRM, Redtail Technology, etc. The integration of a new CRM into the robo-advisory system is important in terms of expanding the client base; however, the priority of this task is lower than improving certain crucial functionality issues. Such tasks may certainly be delegated to an external software development vendor. In this case, the task should be described, including defined requirements, output criteria, and deadlines. Regular meetings, such as daily stand-ups or weekly demos, allow the development team to be aware of each other’s work.

When the software team increases, Agile methodologies and the above described microservices approach to the software architecture appears to be the best choice since it focuses on delivery of business value and accelerates software development without making it messy and chaotic.


To enable efficient growth of the development team, the following steps are required:

  1. Start with a long-term roadmap that:
    1. defines the strategy and works out superficial items within it;
    2. breaks the items down into steps and provides a rough estimate of the time required for each step;
    3. outlines some rough release points.
  2. Provide iterative Agile development with short sprints and releases that take place as early as possible.

Bottleneck 3: Waste of effort due to miscommunication

After the microservices approach to the software architecture has been introduced and the team structure and processes are well aligned, there is a need to reduce the time wasted due to various miscommunications between team members. In most cases, miscommunication and additional requests for clarification occur because of a lack of business domain knowledge and industry understanding by software engineers.

For example, a product manager may want to introduce sleeves for a portfolio-management service. The user story can be described as “Wealth manager should be able to add various sleeve positions to a portfolio.” For a software engineer who is not familiar with wealth-management concepts, this user story may sound like rocket science. Thus, he/she should be able to answer the following questions as a minimum:

  • What is the meaning of portfolio, assets, asset classes, and other basic terms and concepts of wealth management?
  • Who is a wealth manager and what is his/her role? Why should the wealth manager be the only one to have the right to add sleeve positions to a portfolio?
  • What is a “sleeve”? What are the benefits for a wealth manager of having sleeve position capabilities in a portfolio-management solution?
  • What’s the difference between sleeve-level accounting, rebalancing, and reporting?

After that, the engineer should clarify whether he/she needs to support sleeves for all of the abovementioned processes, such as accounting, rebalancing, and reporting, or only some of them. Sleeve-level rebalancing and sleeve-level reporting require sleeve-level accounting, but the reverse is not true. In particular, it is possible to have sleeve-level accounting and sleeve-level reporting without sleeve-based rebalancing. This can be achieved by merging all sleeves each day, rebalancing the account holistically, and then dividing the account back up again. In this workflow, the existence of sleeves has no effect on trading. The question, which we will address later, is whether sleeve-level reports without sleeve-level rebalancing are useful.

Ultimately, the software engineer needs to know what rebalancing is and how it can be done. Also, he/she should be aware that most custodians don’t support sleeve-level accounting, so he/she would need to implement this on his/her own.

To clarify all that, the product manager would need to either describe all the basics in the user story description or answer an enormous number of questions posed by the software engineer.

To save significant time and efforts in advance, we have created a FinTech and WealthTech knowledge base that allows us to train our software engineers. Our knowledge base includes WealthTech domain knowledge (terminology explanation, thorough description of the processes in the industry, careful observation of rules and regulations, and latest analytics) and WealthTech solution knowledge (descriptions of every WealthTech solution not under NDA, observation of problems that arise, ways to identify and resolve each problem, advantages of exploiting particular technologies, examples of APIs and frameworks developed within INSART).

Our WealthTech domain knowledge base is continuously expanding. Today, it includes the following topics:

  • Basic financial terms and concepts: interest basics (interest rate, present value, compounded interest), asset classes (stocks, bonds), performance and metrics, etc.
  • Financial and capital markets: investment basics (capital markets, mutual funds, hedge funds, ETFs), portfolio management (portfolio, optimal portfolio, asset allocation, diversification), wealth-management concepts, etc.
  • Financial engineering and risk management: investor profiling (individual and institutional investors, financial advice, brokerages, custodian banks), orders (execution, rebalancing, restructuring, arbitrage pricing, forwards, futures, swaps and options), financial crisis, etc.
  • Quantitative analysis: vocabulary and mathematical functions used for quantitative modeling, types of models (linear, probabilistic, regression models), simulation and optimization, financial goal-based planning (investors and savers, tax planning), etc.

When training our software engineers, we provide the following activities:

  • Workshops and seminars held in our Competency Center, at which software engineers obtain industry insights and get to know approved practices, share their FinTech and WealthTech experience, discuss solutions, and generate new ideas.
  • Regular meetings with a client’s product management team to discuss and clarify logics and processes in the FinTech and WealthTech industry. Software engineers receive clarifications on core aspects and critical issues.
  • Preparation by each development team of demos with approved practices, processes, and logics in the client’s company. As new software engineers join the team they are referred to the demos, which help them to obtain a general understanding of the working environment.
  • Identification by the FinTech engineering team of the business needs and perspectives of each task prior to every iteration.

FinTech Engineering Approach

At INSART, we use the FinTech Engineering Approach to help our clients get ready to scale their business on the technology side. The approach comprises the following three aspects:

  1. Enable rapid development of new software functionality by introducing a microservices approach and reducing technical debt.
    By dividing monolithic software architecture into microservices, the software development team can be expanded. If there is a lack of software engineers in the in-house team, resources may be utilized from external software development vendors without posing any risk to the system functionality.
  2. Enable growth of the software development team by establishing an Agile approach and well-structured cross-functional teams.
    Expanding the team, regardless of whether it is in-house or external, assumes that project management processes are well established.
  3. Reduce significant time and effort for clarifications and rework by training software engineers in the wealth-management business domain in advance.
    Even if a development team is scalable, the company’s growth depends heavily on the ability of the software engineers to develop high-quality software without wasting time on miscommunication and rework.

Our experience gained during our years of FinTech and WealthTech software development may help FinTech companies, particularly WealthTech startups, stimulate rapid growth of their business.