Artificial intelligence is changing one of the most traditional technology decisions in the financial industry: should we build software internally or buy a platform?
For banks, insurers, and other Financial Services Industry (FSI) organizations, developing proprietary solutions is now considerably more accessible. AI coding assistants and development agents can generate code, tests, documentation, and integrations in a fraction of the time they once required. And this capability will continue to improve.
This makes one question increasingly common: if we can now build it ourselves much faster, why buy it?
It is a valid question, but it may be comparing the wrong things. Because the cost of building software and the cost of owning a software capability are not the same.
Development may end. Responsibility for the product you just created is only beginning.
AI Is Changing Build vs. Buy
The reduction in development costs is not a future hypothesis. AI is already making its way progressively across the entire development lifecycle: requirements analysis, design, code generation, testing, documentation, deployment, maintenance, and system modernization.
This fundamentally changes the traditional Build vs. Buy equation. A financial institution with a strong technology team can now create applications, integrations, and automations that only a few years ago would have required much larger projects.
That is why arguing that an institution should buy software simply because “building it is too expensive” is becoming less convincing. The strategic question is changing: when building becomes much easier, what is actually worth building and owning?
Go-Live Is Not the End
Imagine that a financial institution needs to automate an operation. With AI, its team can quickly develop a workflow that receives information from a core system, applies certain rules, generates a document, sends it to the customer, and updates another system when the process is complete.
The development works, testing is completed, and the solution goes into production. From a project perspective, the objective has been achieved. From an operational perspective, however, this is only the beginning.
Now someone has to ensure that the solution continues to work tomorrow, six months from now, and five years from now. It has to remain available despite changes in volume, provider modifications, new integrations, incidents, vulnerabilities, changes in the business, and evolving user needs.
That problem has a different name: sustained operability.
Building an Operation Is Not the Same as Building the Capability to Operate It
When an automation begins processing hundreds, thousands, or millions of operations, questions emerge that were not necessarily present during the initial development. How many operations are running? How many completed successfully? Which ones are delayed or failed? Where did the failure occur? Was it a workflow problem, a data issue, an API, or a provider? Are SLAs being met? Which operations require human intervention?
There is an important distinction here between monitoring software and monitoring operations.
A technology team can monitor infrastructure, logs, exceptions, latency, or API availability. An Operations manager needs to know, for example, that out of 12,438 operations initiated, 12,107 were completed, 186 remain in progress, 94 require intervention, and 51 failed.
And that person needs to be able to move from this aggregated view to a specific operation and reconstruct its entire journey: the request was received, a validation was performed, a document was generated, a signature was requested, a WhatsApp message was sent, the customer did not respond, an email fallback was triggered, and the operation was ultimately completed.
That is end-to-end operational monitoring. And it does not appear automatically simply because the workflow was developed correctly.
The Real Challenge Appears When Something Fails
Building the happy path is only part of the problem. Real-world operations have exceptions: an API that does not respond, a provider that is temporarily unavailable, missing data, a document that cannot be generated, an expired signature request, a rejected communication, or two systems that temporarily end up in different states.
Then someone has to decide what happens next. Should the operation retry automatically? How many times? Should another provider or channel be used? Should the operation be paused? Should an alert be generated? Should the case be assigned to a person? Can that person correct the problem and resume the workflow from where it stopped?
Mature automation is not defined only by what it does when everything works. It is also defined by how it detects, manages, and recovers from what did not work.
AI Can Multiply This Very Problem
There is a paradox. The easier software becomes to create, the more software an organization can create. AI can enable much smaller teams to produce applications, APIs, agents, workflows, and automations at a speed that would have been difficult to imagine only a few years ago.
This represents an enormous opportunity for FSI, but it can also lead to technology proliferation: more applications, automations, agents, integrations, and components accessing systems and data—and therefore more operations that need to be monitored and governed.
The challenge can quickly shift from “How do we build this?” to “How do we govern everything we are now capable of building?”
In Financial Services, the second question may ultimately prove far more important than the first.
When AI Stops Assisting and Starts Executing
The evolution toward Agentic AI makes this discussion even more relevant. The first enterprise AI use cases were primarily focused on assisting people: finding information, summarizing documents, generating content, analyzing data, or recommending an action.
Agents introduce another possibility: acting.
In a financial operation, an agent could analyze a situation, query different systems, make a decision, generate a document, request a signature, send a communication, wait for a response, use another channel if there is no response, update a system, and escalate an exception to a person.
The challenge is no longer simply governing what AI can decide. Organizations must also govern what it can execute, under what conditions, and within what limits. And afterward, they must be able to reconstruct what it did, for which operation, using what information, and with what result.
The ability to execute more automatically increases—not decreases—the need for monitoring, control, and traceability.
In FSI, Knowing What Happened Is Not Always Enough
There is also a distinction between traceability and evidence. Traceability allows an operation to be reconstructed; evidence allows it to be proven.
An institution may need to determine what information a customer received, which version of a document was used, what communication was sent, through which channel, and when. It may also need to know which rule was in effect, what decision the process made, who modified that rule, whether manual intervention occurred, and what happened afterward.
In financial operations, a solution can work perfectly from a functional standpoint and still be insufficient from an operational or audit perspective. That is why auditability should not be added at the end of a project as an additional feature: it must be part of the architecture of the operation.
Low Code Takes on a Different Meaning in the AI Era
AI also forces us to reconsider the value of Low Code. For years, one of its main promises was faster development. But if AI can generate software in minutes or hours, competing solely on development speed is no longer enough.
The more interesting value of Low Code becomes keeping operations understandable and manageable by people.
Imagine two solutions that AI makes it possible to build equally quickly. In one, the logic is distributed across code, services, scripts, prompts, APIs, configurations, and databases. In the other, the operation remains visually represented as a workflow: event, validation, condition, document, signature, wait, communication, fallback, intervention, and closure.
On go-live day, both may do exactly the same thing. The difference appears six months later, when Operations needs to change a rule, a new person joins the team, Audit needs to understand the process, or the business needs to identify where an exception is occurring.
The question becomes: to modify an operation, do we have to develop software again, or can we modify the operation itself?
A well-designed Low Code platform allows operational logic to remain visible and enables certain changes to be made by authorized users, while IT remains responsible for architecture, security, integrations, permissions, and technology governance. The goal is not to eliminate IT, but to prevent every operational change from becoming a new development requirement.
Software Evolves. Its Users Need to Evolve Too
There is another cost that few Build vs. Buy comparisons include: continuously training the people who use the solution.
A useful platform does not remain static. It adds features, channels, integrations, AI capabilities, controls, and new automation possibilities. Every improvement increases what the product can do, but also what its users need to know.
Someone has to teach users how to use those new capabilities, train new users, document processes, share best practices, and help turn available capabilities into better operations.
That is why the evolution of software also creates an ongoing need for its users to evolve. This is one of the reasons DANAconnect complements its platform with DANAconnect Academy: training is not simply about learning how to use a feature, but also about progressively developing the capabilities required to get the most from the product and apply best practices.
In an internally developed solution, that function must also exist. It may have another name and a different structure, but someone will have to take responsibility for it.
A Platform Also Accumulates Specialized Knowledge
Training users is one part of the problem. The other is developing and maintaining expertise around what the platform enables organizations to do.
Communications are a good example. An institution can absolutely develop the technical capability to send email, SMS, WhatsApp, or messages through other channels. But that does not automatically answer how best to structure a transactional communication, how it should be adapted across channels, when to use a fallback, how to design a collections journey, or which practices may affect deliverability.
The same applies to automation, documents, integrations, and other operational components. Providing a capability is one thing; accumulating knowledge about how to use it correctly is another.
A specialized platform does not accumulate code alone. It also accumulates experience from implementations, new requirements, provider changes, use cases, and problems that have already been solved. That knowledge can flow back into the product in the form of best practices, support, training, and new capabilities.
Maintaining Is Not the Same as Evolving
There is also a cost that is often confused with maintenance: R&D.
Maintenance means ensuring that what already exists continues to work. R&D means ensuring that what exists does not cease to be relevant.
A solution developed today will have to coexist with new technologies, models, interfaces, and forms of automation over the coming years. Providers, APIs, channels, security requirements, user expectations, and agent capabilities will also change.
An institution that decides to build an internal platform must also decide who will continue researching these transformations, which ones should be incorporated into the roadmap, and who will develop the new capabilities that become necessary.
Because an operational platform does not truly end with its first version. It becomes a product that needs to evolve continuously.
Build Can Mean Becoming Your Own Software Vendor
This is where perhaps the least visible cost of all appears.
When an organization decides to internally develop a complex operational capability, it does not need only developers. Over time, it may need Product Management to define the roadmap and priorities; R&D to investigate new capabilities; Engineering and QA to develop and validate them; Operations and Monitoring to ensure sustained operability; Security and Governance to protect and control the platform; Support to assist users; Academy or enablement to train and continuously update those users; and specialized expertise to apply the technology correctly.
It also needs to maintain the traceability and evidence capabilities required to reconstruct and demonstrate what happened during an operation.
Seen this way, the question changes:
Are we developing an internal solution, or are we building our own software vendor?
If the capability is strategic enough, doing so may be completely justified. But the business case should explicitly recognize that decision.
The Cost AI Is Reducing Is Precisely the Most Visible One
Here lies the Build vs. Buy paradox in the AI era: AI is making Build look extraordinarily attractive because it is reducing precisely the most visible part of its cost: building.
After development, permanent responsibilities remain: operating the solution, monitoring operations, resolving exceptions, changing processes and rules, governing users and agents, maintaining traceability and evidence, training users, and continuing to invest in evolution and R&D.
AI will also help reduce the effort required for many of these activities. But it does not eliminate the need for someone to be responsible for them.
That is why the Total Cost of Ownership of a proprietary capability should not be calculated simply as development + infrastructure + maintenance. It should also consider the organization required to operate and evolve it sustainably over time.
So, Build or Buy?
The answer should not be ideological.
There are capabilities that a financial institution should probably build: proprietary risk models, differentiated pricing logic, antifraud capabilities, decisioning, experiences that constitute a competitive advantage, or intellectual property specific to the business. AI makes it possible to invest even more aggressively in these areas.
But there are other capabilities that many organizations need repeatedly: process orchestration, integrations, documents, signatures, cross-channel communications, operational monitoring, exception management, traceability, evidence, auditability, user management, training, and continuous platform evolution.
In these cases, the comparison should not be limited to how much a license costs versus how much it costs to develop the functionality.
The more complete question is:
Do we want to turn this capability into a permanent internal competency?
Build the Differentiation. Buy the Operational Capability.
This is a different way of understanding the role of platforms like DANAconnect in the AI era.
DANAconnect does not exist because financial institutions are incapable of developing software. They will become increasingly capable of doing so. The goal is to provide a Low Code platform on which they can turn systems, data, decisions, and AI into executable, monitorable, governable, and auditable operations, without having to build and sustain internally all the infrastructure surrounding those operations.
Proprietary systems, models, and agents can determine what should happen. DANAconnect helps manage how it happens sustainably: from workflow orchestration to documents and signatures; from cross-channel communications to integrations; from operational monitoring to traceability and evidence.
Around the technology, there are also capabilities that require ongoing investment: support, training through DANAconnect Academy, best practices, specialized knowledge, Product Management, and continuous R&D.
That, too, is part of the product.
The New Business Case
Artificial intelligence does not make the Build vs. Buy decision irrelevant. It makes it necessary to frame the decision better.
It is no longer enough to ask “Can we build it?” The answer will probably be yes. Nor is it enough to ask how long it will take, because that time will continue to decrease.
The more useful question is:
Do we want to be responsible for operating, monitoring, resolving, changing, governing, auditing, teaching, and evolving this capability sustainably over time?
AI is democratizing software development, and that represents an extraordinary opportunity for Financial Services. But precisely because of this, competitive advantage will not necessarily belong to whoever manages to build the most software, but to whoever knows what is worth building, what is better consumed as a platform, and how to turn both into sustainable operations.
Code can be generated faster and faster. Responsibility for what that code puts into production remains.
