Finxact Completes Azure Re-Platforming for Core Banking

Core banking software provider Finxact has announced the completion of a re-platforming initiative that moves its Core-as-a-Service offering onto Microsoft Azure. The move is a direct response to growing demand from the company’s regional and super-regional bank clients and prospects who require Azure-based infrastructure to meet their own procurement, compliance, and operational standards.

What Is Finxact Core-as-a-Service?

Finxact provides a SaaS-delivered core banking platform designed to act as a modern System of Record (SOR) for financial institutions. Key capabilities include:

• Secure record-keeping and transaction processing with enforced system, business, and regulatory rules
• Elastic scalability — technically, functionally, and commercially — to support everything from core conversions to greenfield digital-only bank launches
• An open banking API designed to allow banks to deliver omnichannel and event-driven services without rebuilding their core

The platform is built on the premise that critical banking workloads — traditionally kept on-premises or on private infrastructure — can be securely and reliably operated in the public cloud, while still satisfying the operational continuity and compliance requirements regulators expect of core systems.

Why Microsoft Azure?

Finxact selected Azure based on Microsoft’s compliance coverage, security tooling, and its established position as a trusted cloud platform in the financial services sector. The partnership involved co-development of the datacenter infrastructure configuration to align with Finxact’s application design and deployment patterns.

“Our team worked side-by-side with a talented and attentive team from Microsoft to provision our datacenter infrastructure in a way that optimized our application design and deployment. It was an excellent outcome, and we’re looking forward to future co-development efforts with the Microsoft team to position our joint customers well for enhanced analytics, AI, and other Microsoft Azure solutions.”

— Jim Joyce, Chief Technical Officer, Finxact

“Many banks are looking for efficiency and agility gains from technology advancements. By adopting Microsoft Azure, Finxact will be able to help its clients accelerate their digital banking presence through greater computing scale, unlocking new capabilities.”

— Luke Thomas, Head of Banking, U.S. Financial Services, Microsoft

Broader Context: Cloud Adoption in Core Banking

When Finxact first launched Core-as-a-Service, public cloud adoption in banking was largely limited to front-office workloads — productivity suites and customer-facing channel applications. Running a core banking System of Record on public cloud infrastructure was, and remains, a significant architectural and regulatory decision for any bank.

Finxact’s Azure availability represents an argument that the security controls, geographic redundancy, and compliance certifications available on hyperscale cloud platforms can meet — and in some respects exceed — what banks can achieve in their own data centers for core processing workloads. The pitch is particularly targeted at regional and super-regional banks that may lack the capital and engineering resources to maintain differentiated on-premises infrastructure.

Co-Development Roadmap: Analytics and AI

Beyond infrastructure, Finxact and Microsoft are also pursuing co-development in areas where core transaction data can feed downstream analytics, AI, and decisioning tooling. Microsoft Power BI is cited as one example of a tool that could ingest and surface insights from core transaction data streams, though the specific integrations are described as being in active development rather than generally available.

Early Customer Adoption

At the time of this announcement, middle-class-focused digital bank One had selected Finxact’s Core-as-a-Service to power its banking operations, representing one of the early production use cases for the platform.

About Finxact

Founded in 2016, Finxact describes its mission as freeing banks from the constraints of legacy systems so they can build the bank they envision rather than the bank their technology permits. The company has raised funding from a range of strategic investors in the banking and fintech ecosystem, including the American Bankers Association (ABA), First Data, Accenture Ventures, SunTrust Bank, Live Oak Ventures, and Woodforest National Bank, among others.

The company positions its platform as enterprise-class, public cloud-hosted, private-data architecture with a completely open banking API — a combination it argues differentiates it from both legacy core vendors and newer but less capable cloud-native alternatives.

What Digital Transformation Actually Demands from IT

ITIL frames digital transformation as the use of digital technology to enable significant improvements in business outcomes—improvements that would not be feasible through non-digital means. In practice, that means organisations need to move faster, experiment more freely, and release new features in days rather than months.

For years, a common complaint from business stakeholders was that IT was a bottleneck: new features took too long, opportunities were missed, and revenue was lost while waiting for a release cycle. CI/CD directly addresses that bottleneck by automating and streamlining the path from a developer’s commit to a running production service.

Breaking Down the CI/CD Pipeline

CI/CD is a collection of practices primarily rooted in software engineering, though they are now applied equally to infrastructure-as-code and platform configuration. The three core concepts are distinct but build on each other.

Continuous Integration (CI)

Continuous integration is the practice of merging developer changes into a shared repository frequently—often multiple times per day—and automatically building and testing the resulting codebase. The goal is to catch integration errors early, when they are cheap to fix, rather than discovering them during a painful late-stage merge.

• Every commit triggers an automated build.
• Automated tests (unit, integration, static analysis) run against each build.
• Developers receive rapid feedback on failures.
• The main branch is kept in a consistently releasable state.

Continuous Delivery (CD)

Continuous delivery extends CI by ensuring that every build that passes automated testing is packaged and ready to be deployed to production at any time. The decision to release is still made by a human, but the technical work of preparing the release is fully automated.

• Releases become low-risk, routine events rather than high-stakes projects.
• Organisations can choose when to release based on business need, not on engineering readiness.
• Staging and pre-production environments mirror production, reducing surprises at release time.

Continuous Deployment

Continuous deployment goes one step further: every change that passes the automated pipeline is automatically promoted to the production environment without manual approval. This enables multiple production deployments per day and is the model used by high-velocity engineering teams at many large digital companies.

Continuous deployment is only viable when the automated test suite is comprehensive and trustworthy. It depends on continuous delivery as its foundation.

Why the Pipeline Matters for Business Outcomes

Together, these practices create an uninterrupted flow of changes from development to production. The business benefits are direct:

• Faster feature delivery: New product and service features can reach users in days instead of months, allowing the organisation to respond quickly to market opportunities.
• More reliable deployments: Smaller, more frequent releases are easier to test, roll back, and reason about than large, infrequent releases. This reduces operational risk.
• Reduced cost of failure: Automated testing and rapid feedback loops catch defects early, when fixing them is far less expensive.
• Infrastructure parity: The same CI/CD principles applied to application code can be applied to infrastructure-as-code, ensuring consistent, auditable environments.

CI/CD Is a Technical Enabler, Not a Complete Strategy

It is important to be clear about what CI/CD does and does not do. It is a technical enabler—a set of tools and practices that make fast, reliable delivery possible. On its own, it is not sufficient to transform a digital organisation.

For CI/CD to deliver its full potential, it needs to sit within a broader organisational context that includes:

• Lean and agile principles governing how work is planned and prioritised.
• Cross-functional product teams that unite technology and business expertise, rather than siloing them.
• Modern product management that treats digital services as continuously evolved products, not one-time projects.
• A culture of shared ownership over reliability and quality, spanning both development and operations.

Digital products are only effective when technology and business expertise are applied together throughout the entire product and service lifecycle. A CI/CD pipeline that automates deployment into a dysfunctional organisational structure will accelerate the delivery of the wrong things just as efficiently as it accelerates the right ones.

Management Implications

For IT managers and engineering leaders, adopting CI/CD requires both technical investment and organisational change:

• Test automation must be treated as a first-class engineering concern. A pipeline is only as trustworthy as its test coverage.
• Teams need ownership of the full delivery pipeline, not just the code they write. This encourages accountability for reliability.
• Release processes need to be simplified and documented so that automation is straightforward and exceptions are visible.
• Metrics matter. Deployment frequency, lead time for changes, change failure rate, and mean time to recovery (the DORA metrics) are useful indicators of pipeline health and team performance.

The transition from infrequent, manually managed releases to continuous delivery is a significant shift in how engineering teams operate. It requires investment in tooling, in testing, in culture, and in the trust between development, operations, and business stakeholders. But for organisations serious about competing in a digital-first market, it is now a baseline expectation rather than an advanced practice.

This article is based on an original piece published on Computer Weekly (December 2019).

From Brick-and-Mortar to Brazil’s Digital Powerhouse

Dubbed “the Amazon of Brazil,” retailer Magazine Luiza — universally known as Magalu — has become one of the most widely studied digital transformation success stories in retail. Between January 2015 and mid-2019, the company’s stock price reportedly increased more than 18,000% in value. That figure is striking on its own, but it becomes extraordinary when you consider that Brazil was simultaneously enduring its worst recession in modern history when the rally began.

Less than a decade earlier, few would have predicted such an outcome. Magazine Luiza was a predominantly brick-and-mortar operation struggling with economic instability and rising pressure from digitally-native competitors. What changed? And what can enterprise leaders learn from how Magalu engineered its transformation? Here are five actionable lessons.

Lesson 1: Change Must Come From the Top

Magalu CEO Frederico Trajano did not frame digital transformation as a series of app launches or isolated technology projects. His vision was comprehensive: move technology from a back-office support function to the strategic core of the business.

“Technology [must move] from the background to center stage — and [be] seen as the brain of the business. Hierarchical structures, paralyzed by excessive bureaucracy, the fear of change and attachment to past successes, usually strongly reject the digital culture.”

— Frederico Trajano, Magalu Q4 2016 Earnings Statement

This top-down commitment matters because digital transformation is as much a cultural and organizational challenge as it is a technical one. Without clear executive sponsorship, the typical enterprise stalls: individual teams digitize existing processes without rethinking them, silos persist, and KPIs never evolve to reward new behaviors. Meaningful transformation requires leadership that is willing to:

• Redefine incentives and performance metrics to reinforce digital-first behaviors
• Break down organizational silos that block cross-functional collaboration
• Invest in retraining and reassuring employees who fear displacement
• Communicate a clear vision that connects technology investment to business strategy

Without that mandate from the C-suite, even well-funded technology programs tend to produce incremental efficiency gains rather than genuine business model change.

Lesson 2: Innovators Need Room to Innovate

Trajano recognized early that transforming a large organization requires a dedicated engine for innovation. In 2012, he established Luizalabs — an internal technology and innovation team that started with a small group of developers and eventually grew to more than 900 employees spread across four buildings in two Brazilian states.

Two deliberate decisions made Luizalabs effective rather than merely symbolic:

1. Access to core systems. Developers were given direct access to Magalu’s live business systems, rather than being isolated in a sandbox working on theoretical prototypes with no path to production.
2. Freedom from heavy governance. Luizalabs was exempted from the company’s slower, bureaucratic approval processes, allowing it to operate with startup-like velocity.

“The idea was to try to break the entire system — to show that it’s possible to have IT close to the business guys. Before, there were very heavy processes. It would take two months to get all the information.”

— Andre Fatala, CTO and head of Luizalabs

By adopting agile development practices, automated testing, and lighter-touch governance tooling, Luizalabs compressed delivery cycles from months or years down to weeks or days — and created a repeatable blueprint the broader organization could learn from and scale.

Lesson 3: IT Agility Is a Precondition for Business Agility

Speeding up software delivery requires more than a motivated team — it requires an architecture that supports rapid, independent change. Magalu’s legacy systems were largely monolithic: large, tightly coupled codebases where changing one component risked breaking others, and where multiple developers could rarely work in parallel without stepping on each other.

Migrating everything at once was not practical, so Magalu adopted a two-speed IT strategy:

• Front-end acceleration: Customer-facing applications were decoupled from back-end systems using APIs, allowing front-end teams to iterate quickly on user experiences without waiting for back-end changes.
• Back-end modernization at its own pace: Core systems of record were maintained and gradually re-architected without blocking customer-facing development.

“In 2013 we had an e-commerce platform, and even a library of APIs, but those APIs were accessing an overstretched backend application built with 150,000 lines of code. Deployment of new APIs was slow, we were burdened with undesirable dependencies, and we faced scalability challenges as well as distributed responsibilities across siloed teams.”

— Andre Fatala, CTO, quoted in a Google Cloud blog post

Over time, this two-speed approach evolved into a full microservices architecture — where applications are composed of small, independently deployable services rather than built as monolithic blocks. Each service is exposed via a well-defined API, making it discoverable and reusable by other teams. API management tooling gave Magalu visibility into how its business capabilities were being consumed, enforced access controls, and generated usage analytics across the platform.

The practical result: developers could combine existing services like building blocks to ship new products without rebuilding functionality from scratch each time.

Lesson 4: Digital Platforms Unlock New Business Models

With a modular, API-driven architecture in place, Magalu could pursue business strategies that would have been impossible on its legacy systems. In 2016, the company launched a third-party digital marketplace, allowing external sellers to list products under the Magalu brand.

The impact was immediate and measurable:

• The legacy integrated system had supported fewer than 50,000 SKUs.
• The marketplace eclipsed 1 million SKUs by late 2017.
• It eventually grew to include more than 8,000 sellers offering 7.5 million SKUs.

Because the marketplace is API-driven, onboarding new merchants adds virtually no marginal infrastructure cost. Automated monitoring and rule enforcement keep the seller ecosystem healthy without requiring proportional increases in headcount.

Magalu also introduced Lu, an AI-powered virtual influencer designed to help shoppers discover products — an early signal of where the company’s ambitions were heading. By 2018, Trajano was describing a much broader vision:

“We are not only building an app, but rather a ‘superapp’: a digital environment where customers can go shopping, pay bills, top-up their mobile phones, hire transportation services, buy lunch. By attracting partners to the superapp environment we will increase our chances of attracting new customers, whose interactions with the company will be even more frequent and meaningful.”

— Frederico Trajano, Magalu Q4 2018 Earnings Statement

The platform mindset — building infrastructure that others can build on — is what separates companies that digitize existing processes from those that create entirely new categories of value.

Lesson 5: True Transformation Reaches Every Corner of the Business

Customer-facing digital experiences are a critical piece of transformation — but they are not sufficient on their own. Magalu recognized that a slick e-commerce front end would disappoint customers if the operational reality behind it could not deliver. Transformation had to run deeper.

Specific operational changes included:

• In-store employee tools: Sales associates were equipped with apps that surfaced local inventory data, enabled card payments anywhere on the shop floor, and guided customers through digital credit verification — eliminating friction at the point of sale.
• Last-mile delivery: Thousands of contract drivers use a Magalu app in a rideshare-style model to fulfill online orders, compressing delivery windows and reducing dependence on traditional logistics providers.
• In-store pickup: Technology was applied to make click-and-collect experiences simpler and more reliable, bridging online and physical retail.

The lesson here is straightforward: a great digital storefront backed by a slow, manual operation will erode customer trust. Sustainable digital transformation requires that the entire value chain — operations, logistics, employee tooling, and finance — evolves alongside the customer experience.

Final Thoughts: Technology Is a Road to Change, Not Change Itself

Magalu’s story is not a story about any single technology. It is a story about using technology deliberately and consistently to serve customers better, empower employees, and open new business models. Enterprises that frame digital transformation around specific technologies — a cloud migration, a machine learning initiative, a mobile app — risk achieving incremental efficiency improvements while leaving the fundamental structure of their business unchanged.

The five lessons from Magalu point to a different approach:

1. Secure genuine executive commitment — not just sponsorship, but active vision-setting and cultural leadership.
2. Create protected space for innovation, with real access to real systems and freedom from bureaucratic drag.
3. Modernize your IT architecture so that business agility is technically possible, not just aspirationally desired.
4. Think in platforms and ecosystems, not just products and features.
5. Extend transformation through the entire operating model, not just the customer interface.

Technology is a means to an end. The end is a business that can change as fast as its customers’ expectations do.