Interview with César Camargo, CEO at SNGULAR

Could you tell us a bit about your experience developing technology for financial companies in Europe and the Americas?

It’s a typical practice in the banking sector to subcontract critical services like creating new accounts or customer acquisition. This can have negative consequences since companies lose control over new clients. They don’t always know what their client experiences are or what checks must be done to ensure their products are suitable. This has resulted in the loss of many clients.

To avoid this problem, more and more companies are deciding to internalize this process. That’s where we come in. Many companies in this sector have relied on our experience and knowledge of building these systems. We’ve taken on projects of this kind for banks in the US, Europe and Mexico.

Our work begins with defining the technological architecture we have to develop. Then, we decide on the development technologies, the process to follow and how it will all link up to different areas of the business.

Outsourcing critical systems and records does have an advantage. Namely, it allows you to get to the market much faster. It’s more common in the US than in Europe. But it does have significant drawbacks like not being able to customize the customer experience appropriately or not having full control of the platform development roadmap. Sometimes it means companies can’t achieve some of their own business goals since they’re constrained by the goals of the third party.

With all this in mind, from SNGULAR in the US, we are working with a bank that wants to internalize this platform and they asked us to help in accelerating its development.

Now that the platform is up and running (all within the deadline), the bank is noticing its positive effects. It's gaining new clients and accounts thanks to internal management. At the same time, the customer experience has improved dramatically since they have more control.

We are in a new era of banking technology. All the infrastructure on which we develop is now based on containers. We work with Java and Spring, technologies that are common to all banks in Europe and the US.

There are two ways to approach this development. First, you have the traditional way of using a workflow, with a monolithic system which takes away flexibility and the ability to implement or deliver new updates. Or we can use a different approach, a choreography model, which is the one we decided to apply with the client's enterprise architecture team. Here, we define the workflow and the call orchestration through an event-driven system and the use of business rules that controls which action to take next. It was all implemented as a microservice, so we could apply continuous integration. Thanks to this, we have the control, the ability to personalize the experience only by working with business rules and we do not have to code any choreography or service orchestration.

In terms of performance, this model has been hugely advantageous. That’s primarily because we didn’t have to deal with typical product constraints and could scale as much as we wanted.

The biggest challenge, on the other hand, was that it was our first project with the bank. Usually, when we’re working with a company of this size, and we’re talking about one of the ten largest banks in the US, we start with a smaller project. Building a platform for new clients and onboarding was not only larger than usual, but also highly critical.

After we started the project, we realized that they were not ready to build the platform as we had designed it. Eventually, we built the architecture from scratch using open-source technologies and helped them launch this new technological environment within the organization.

Helping them update with open-source technologies has been extremely satisfying. Now, all the projects they are developing are executed with the same architecture that we created.

Could you go a little deeper into the details of how we built this platform?

On the front-end, we are using Angular 8. We are working with atomic design and consuming all the data from the back-end system through an API gateway. Going down a bit further, we are building pure REST API endpoints. This REST API is being implemented as a wrapper in an Openshift orchestration engine. We are using Sprint Booth 2 and reactive Java ARGS to build the reactive components. We are also using Kafka, not as a pure event source, but more as an event broker.

We are applying a choreography, which is a way of implementing event-driven architecture. We launched the event through Kafka and used an open-source business rules engine called Drools, which is well known in the Java world. With these rules, we are occupying the space that a VPN would normally occupy.

Why did you opt for business rules over a VPN?

Banks’ VPNs are usually very inflexible and require three months of preparation before you can get the first draft of a workflow. It just wasn’t feasible.

At the same time, we weren’t just implementing a REST API. We needed an event-driven architecture, so we are building something we call a micro-listener. We are implementing microservices, but the interface is a Kafka listener, so they react to events that are launched and activated by different systems. Each micro-listener has a unique responsibility that involves a specific banking system or a third-party system. This allows us to work on the ATDD model better because we can isolate the complexities or the functionalities and test them independently.

We are following the typical approach when it comes to working: gitflow, code reviews, pull request…. methodologies that are already typical in a cutting-edge technology company, but aren’t as widespread as we may believe.

In the end, the solution was not only appreciated by the technical team, but also by the product owner and the customer service team.

What would you say are the keys to a successful software development project?

We’re speaking about developing a type of platform that we had already built. This gave us more confidence because we knew what the challenges were going into it. At first, they wanted us to deliver earlier but the time frame was not reasonable, something which we helped them understand. There’s a lot we can do, but everything has a limit.

If I have to sum it up, I think the key to success was trust. They trusted our understanding of the project, they trusted our knowledge of the technology and they trusted our experience.

The other key factor was demonstrating our ability to deliver value. This is our promise, that we always fulfill our commitments. Clients trust us because they know that when we say that we are going to deliver something, we always deliver no matter what. Of course, there are many obstacles, but we always find a way to find an alternative solution. And we do it by defining a personalized solution that, in some cases, becomes the official one.

What has been the impact of this platform?

Now that the client has an internal platform, it can fully control the client experience. This is very important during the onboarding process because, at the end of the day, a bank is an e-commerce company. When you sign up for a new account or become a bank customer online, you are ultimately in a typical e-commerce channel conversion funnel. If this is done internally, you can control the entire process. The platform is also independent of the product, which is a very complex issue because banks normally have hundreds of products.

I remember a bank in Spain that had 120 types of checking accounts, so you had to build this type of system that allowed more and more products to be added quickly. In the end, what you get are hundreds of products originated or created through this platform.

For this US bank, we created an origination platform, which is basically an income platform. This is so critical because it is the sales part of the bank. It’s also why it makes much more sense for it to be internal. That way you have internal control, can monitor its activity and have KPIs that allow you to measure and improve.

In the US, they like technology and processes that are specific to the financial industry. If you have worked for three banks, don’t be surprised if the next client who calls you is another bank. Because for them, technology and industry are closely related. Although at SNGULAR we can build things with the same technology for completely different industries, the banking sector is difficult to convince.

A bank will always ask you about your previous experience implementing the kind of concrete solution they need and try to make sure that you understand their business requirements, their product owners, their business team, etc. They don't trust someone who tells them they can develop a product and that’s all. We can’t just be the delivery team, but we have to be the glue that connects the sales team to the delivery team.

How do we sell our services to banks?

To sell technology development services to banks, having knowledge of the industry is extremely important. We have to be experts in technology for banks and we have to be a disruptive team because if we are working with traditional tools (using VPN, ESB, product-oriented architecture, etc.), we don’t usually win. And we don’t take that route because other companies have personnel certified by the product and have a huge amount of experience implementing a specific version of ESB or a VPN. We don’t have that experience and frankly, we don’t need it.

So, the way we can really be agile in the financial sector is by thinking about how we can reduce time to market and how we can bring the most value to lines of business. This is particularly key now that almost all banks are using agile methodologies. This is great for us because agile is understood differently in different banks. Some are more mature in the methodology, but others are less so. In any case, it is a great opportunity for us because the big traditional players cannot be as agile as we are because the delivery cycles are longer. We, on the other hand, can deliver as fast as we can or as fast as they allow us to.