The team behind Finologee was brought together by a shared penchant for pushing technology’s bleeding edge. Their pursuits began 20 years ago with Luxusbuerg, Luxembourg’s very own social networking platform whose arrival preceded Facebook’s by five years. Next came routing and micropayment company Mpulse, followed by Digicash, a mobile payment solution for retail banks, in 2012. In 2017, the insight and experience acquired along the way culminated in Finologee, a regtech-focused platform that lets financial industry players harness fintech solutions. All of its business lines are rooted in highly efficient transactional platforms, the essence of Finologee. Its lean, skilled and exclusively in-house development team continues to rapidly integrate the latest breakthroughs in technology. CIO Georges Berscheid dissects the technical fundamentals that underlie the effectiveness of the Finologee platform.
by: Finologee
photo: Finologee
featured: Georges Berscheid
Listen to article (Part I)
How does your operational & development approach facilitate quality?
Like any modern team, Finologee uses a fully agile process, allowing for quick adjustments in response to changing customer requirements and the reallocation of efforts between business lines in response to changing priorities. Since we work with a wide spectrum of topics, spanning messaging (Mpulse), payments (PSD2 & Digicash) and KYC (onboarding & remediation), having a flexible process is key to the success of each individual business line.
But we don’t just develop applications, we also run them. This means complying with ambitious service-level agreements, providing top-notch customer service and delivering operational, compliance, security, business and financial reporting – all within the very strict boundaries of a company regulated by the financial services sector.
Can you walk us through Finologee’s architecture?
Finologee’s applications use a microservice architecture that allows for optimal separation of concerns with regard to the different components. Loose coupling of the services through well-defined interfaces facilitates individual life-cycle management. Microservices can be upgraded independently without interfering with existing customer applications, as long as the interface contracts’ evolution supports backward compatibility.
We package our microservices as Spring Boot applications running in lightweight Docker containers that function in any environment, from the developer’s machine during the development phase to the datacenter environment during production deployment. Runtime environments are deployed together with the applications, minimizing the risk of issues arising due to variations in the infrastructure setup across different environments.
Would you say that Finologee prioritises the testing phase?
Absolutely. Optimized testing procedures are crucial for maintaining high-quality software products. Finologee’s architecture allows fully automated testing through build pipelines that run regression tests in a dedicated testing environment. The arrival of new code to the repository triggers this procedure. So, we discover bugs early in the development process and have the chance to fix them before any harm comes to the production environment.
All components and services have automated integration tests that identify any unexpected changes in the behavior of another service that could negatively affect its own functionality.
Listen to article (Part II)
When it comes to seamlessly running your many microservices, why did you choose to go with Kubernetes?
Kubernetes lets us orchestrate hundreds of Finologee microservice instances in one production environment. We run all of our applications on a multi-datacenter managed Kubernetes cluster. By doing so, we achieve superior redundancy and fault tolerance, a centralized control and monitoring center, and auto-scaling of applications to respond to peaks in demand. All of this, with a flexibility otherwise only seen with public cloud infrastructures, happens against the backdrop of multiple Luxembourg Tier IV datacenters possessing the highest security and availability standards. Our Kubernetes environment can be completely set up and configured using Infrastructure as Code. Adding new applications or altering the infrastructure of existing applications is always just a few lines of code away. In the case of a major disaster, our complete production environment could be restored from scratch in a couple of hours.
How do you manage financial sector APIs?
These days, APIs are everywhere. They are used to create and enhance existing business applications via building blocks that add specific functionality, while staying architecture-agnostic.
APIs need to be managed: new versions of APIs are provisioned, old versions deprecated and decommissioned, access to APIs controlled through standardized authentication and authorization procedures, monetization implemented using flexible tariff plans, and usage and performance statistics provided through a powerful analytics platform.
We work to remain a forerunner when it comes to managing the whole lifecycle of regulation-compliant APIs for the financial sector – whether in the fields of messaging, payments or KYC.
To support this strategy, we chose IBM’s API Connect for multiple reasons: it perfectly blends into our existing Kubernetes infrastructure; natively supports hybrid cloud setups that allow easy infrastructure scale-up and scale-out; and is a full-featured API management product based on a solid core platform with a proven track record in both small and large organizations around the world. Lastly, it’s been identified as a leader in the Gartner magic quadrant for several years in a row,
What do Finologee’s security measures look like?
One thing the team has learned through decades of experience in technology is to take security extremely seriously, and we do. Security is not something we address retroactively: it’s built into every aspect of Finologee’s development process, from application and infrastructure architecture, to development and testing, to deployment and the running of applications. Because it’s better safe than sorry, we elect to have our applications audited and penetration tested by external specialists.
We adopt a security-by-design approach to building applications, using market best practices, in order to minimize the risks related to processing highly sensitive information, especially in a significantly regulated environment.
We’ll never stop optimising our infrastructure architecture and evaluating the latest innovations in software development. There’s no end goal when it comes to delivering better applications to our customers as quickly as possible. We just keep pushing the goalpost further ahead and evolving toward it.
