This is in addition to the most important stakeholder, the users! Of course, the other stakeholders are engineering, architecture, design, and product.

Each of the stakeholders have different requirements to navigate.

On the engineering and product side, one of the key skill sets to have is being able to ask insightful questions to truly understand the requirement. Then you’ll be able to narrow down the scope and better understand the tradeoffs.

What are some of the engineering challenges to overcome?

On the backend, there are many, including:

Using microservices to effectively scale

3rd party integrations with reporting agencies, such as LexusNexus, Transunion, and Equifax, which aren’t always the most flexible

Writing sophisticated algorithms to effectively score something with many data points, such as a borrower’s loan application

Concurrency issues with calls to the database, for example, when multiple investors with to purchase the same borrower’s note at the same time

Performance and load times, for example, how quickly your rate and loan offers appears versus competitors. If yours is too slow, this could impact your revenues.

How do you think about architectural tradeoffs?

On one of our clients, we built the initial MVP using microservices. This was a decision we made after some key learnings from building another application for which we used a single server.

Microservices allowed us to build horizontally and we also leveraged AWS. This enabled us to scale the platform and not rely on having one server to handle everything. The smaller components could be replicated on the fly, allowing for variances in traffic flow, and not adding more memory, which was great for synchronization.

The downside to this was when something needed to be changed, there are more dependencies and also figuring out which component to put the responsibility of the new feature on. The other downside is as more traffic flows to the platform or application, the costs of AWS can significantly increase, which the finance team will notice!

It’s important to be thoughtful in the initial platform design. Also, when building a new system or feature, you want to be just ahead of the regulatory curve. Usually, FinTech products are tied to legal validations and agency auditing activities. It can take time to go through these validations, so you don’t lose money while waiting for approvals. Of course, building ahead of regulations means, occasionally a feature won’t be approved, requiring more work for engineering to adapt to the regulation, and an adjusted timeline, which creates a lags time to catch up to the market.

What are considerations when determining which technologies to use?

In FinTech, the stakes are high. Although modern technologies, libraries, and frameworks are important, the degree of maturity of the technology is rigorously studied.

For example, Java is a popular language because it’s been validated thousands of times by other technology stacks and proven to work. There are also a large number of engineers who can program in it and a large community of resources. Others are so new that FinTech companies will wait a while to see how it holds up before implementing in their own organizations.

This isn’t as critical in lower stake industries

What types of backgrounds do you look for when hiring backend engineers?

Generally, I care less about their knowledge of a particular language and much more about their approach towards problems. For example, I’ll ask a candidate to describe how they approached synchronization on their most recent project, how they analyzed the problem, what approach they used to solve it, and what was the result. Also, if they could do it over again, what would they do differently.

Also, engineers who have worked in either FinTech or other environments with multiple stakeholders from the business side, so they know how to navigate the complexities effectively.

Lastly, FinTech is much more rigorous in approach. It’s important to get the product right when dealing with people’s money, so there will be more debate and discussion on methodologies prior to shipping. Being eager to learn and putting your ego aside in favor of the best solution is important.

Co-Authors

Matias Gagliano is a Technical Leader with True North. He has spent more than a decade building technology platforms and products for innovative companies, including more than 5 years on FinTech. He holds a degree in engineering from UNICEN and in his spare time enjoys grilling and eating asado.

Brian Samson is a CoFounder of True North, where he leads strategy, operations, and delivery. Prior, he was on the leadership team for 3X startup exits. He holds an MBA from UCLA Anderson School of Management.