iuvity and the art of saying yes

A payment refused is an oddly ambiguous event. Somewhere, a fraud analyst may have prevented a theft. Somewhere else, a perfectly ordinary person is trying again, wondering why their own money has become inaccessible. To the system, both events can look like successful enforcement. To the customer, the difference is everything.

This is the territory occupied by iuvity, a software supplier whose name is considerably less familiar than the banks it serves. Its work stretches from the screen on a phone to the decision about whether a transfer should proceed. The interesting part is what happens when those two responsibilities collide.

The expensive mistake nobody celebrates

In September 2026, iuvity published a case study about Bancolombia. The bank already had fraud technology, including PROFILER. Its difficulty was managing a complicated collection of rules that required manual adjustment. Adding another control could also add another reason to inconvenience an innocent customer.

SARA, iuvity’s prescriptive analytics product, examined that rule system and recommended changes. According to the company’s account, Bancolombia gained 30 percentage points in fraud detection, reduced declines of legitimate transactions by 25%, and cut redundant rules by 50%. These are reported customer outcomes, rather than promises about every deployment.

The distinction between the products matters. PROFILER makes assessments as activity happens. SARA evaluates how an antifraud system performs and proposes better rule combinations. Banks can buy that analytical layer while retaining an existing provider. For an institution with years of investment already embedded in its systems, that is a practical purchasing proposition.

The app is only the beginning

iuvity began as TODO1 in 2000. Contemporary reporting described banks in Venezuela, Colombia and Ecuador collaborating on internet banking. The opportunity was straightforward: financial institutions could reach people through a screen, beyond the geography and opening hours of branches. Making that service dependable would require rather more than a website.

Today, iuvity’s Digital Channels offering covers consumer and business banking. Customers can authenticate, make individual or batch payments, manage beneficiaries and communicate with their institution. The buyer is a bank, credit union or fintech; the person pressing the button is the ultimate user. Those audiences have different needs, and the product must accommodate both.

Underneath sits the Open Service Platform, or OSP. It provides more than 300 APIs and layers for orchestration, business services and integration. Think of a transfer as a small procession: the interface collects an instruction, business logic interprets it, and connected systems must execute it. A tidy screen cannot compensate for a broken procession.

The company’s partnerships explain its place in the market. A 2021 agreement joined Modyo’s experience software to iuvity’s service platform. In 2023, Mambu brought a prebuilt connection to cloud deposit and lending systems. MX added account aggregation. iuvity occupies the connective space between the customer experience and the machinery of banking.

Its micro frontend approach divides the interface into smaller components. In principle, that lets an institution change a particular journey with less dependence on a single, all-encompassing application release. The appeal is control over change. The actual work still includes integrations, testing and the institution’s own requirements.

A fraud is a network

The security story has a similarly specific origin. Neo4j’s customer account says iuvity developed its own fraud application after a commercial tool stopped meeting customer needs. Edgar Osuna, its chief data and analytics officer, needed a way to examine relationships quickly enough for live banking activity.

Graph technology stores connections as part of the data structure. Accounts, devices and transactions become linked clues. Neo4j’s later technical explainer describes combining those relationships with pattern matching, anomaly detection and machine learning. It reports a graph spanning 250 million nodes and 2.2 billion relationships.

The most useful evidence is the comparison. Osuna described testing against the previous product using the same banks and data, achieving twice the detection rate at the same false-positive rate. Holding that second measure steady makes the first meaningful. Otherwise, catching more fraud could simply mean stopping more people.

“In the end we’re serving the person using the app.”

Edgar Osuna / Chief Data & Analytics Officer

A business built to stay behind the scenes

The iuvity name arrived in 2022. Aquila acquired TODO1 Services, Inc., doing business as iuvity, in August 2023 and said it would remain an autonomous business unit. Aquila belongs to Vela Software within Constellation Software. The acquisition placed a specialist banking supplier inside a group organized around long-term software ownership.

The commercial model is enterprise software and services. OSP describes a SaaS model; SARA advertises subscriptions. Integration, hosting and fraud consulting surround the software. The company’s stated cultural values include accountability and reliability, unglamorous words that make sense when clients depend on a service operating continuously.

Its competitive argument is therefore about the scope of the relationship. A bank could assemble separate channel, integration and fraud suppliers, or build more of that stack internally. iuvity offers connected capabilities and the option to purchase individual pieces. That flexibility is useful only if the boundaries remain clear: who changes the interface, who owns the risk decision, and who answers when a payment fails?

Measure the yes as carefully as the no

There is a useful lesson here for buyers: evaluate the decision, then the technology. Ask for detection and legitimate-decline rates together. Compare equivalent periods and data. Inspect which rules contribute useful information. A higher alert count may represent extra work rather than better protection.

There is an operational price to getting this wrong. Every unnecessary alert needs attention; every avoidable decline creates a problem for someone trying to transact. Evaluating those costs alongside fraud losses gives a purchasing team a fuller account of what the software is doing.

That approach depends on reliable fraud outcomes, usable transaction data and agreement about acceptable risk. Without them, an elegant model can optimize the wrong target. iuvity’s most persuasive proposition is the ordinary customer at the other end of the transaction: someone whose payment should go through, and whose bank ought to know why.