Opus fixes the machinery behind the money

The revealing number in an Opus case study is 30. A financial institution’s payment gateway team was completing 30 story points of work. Six months later, Opus says, that figure had reached 53. Somewhere between those numbers sits a familiar banking problem: customers want the next thing, while the machinery delivering the current thing is already difficult to change.

Story points are a team’s estimate of work, rather than a stopwatch for money. Still, the case is instructive. Manual releases, weak test coverage and tightly connected software had made change risky. The difficulty was embedded in the delivery process. Adding another payment feature meant asking that same fragile process to carry more weight.

First, find the jam

Opus describes a phased intervention: onboarding, a common delivery framework, automated build-and-release pipelines, and a workshop to map how work moved through the organization. The workshop examined delivery velocity, deployment frequency, cycle time and defects escaping into production. It informed a roadmap; AI agents then assisted code review, testing and deployment.

The reported result was the move from 30 to 53 points per scrum team, alongside lower cost per feature. Those are company-reported outcomes for an unnamed customer. They describe a useful operating sequence, though: locate the constraint, set a baseline, change the process, measure again. A bank contemplating AI can borrow that sequence before borrowing anybody’s software.

The space behind the button

That is the territory Opus occupies. Founded in 1997, the company works for banks, credit unions, payment providers and fintechs. Its assignment might involve updating an aging payment switch, connecting a new network, improving merchant onboarding or building the APIs through which other businesses access financial services. The work continues into cloud engineering, security, testing and operations.

Consider the difference between accepting a payment and understanding it. A transaction must arrive in a format another system recognizes, follow the correct workflow, and leave records that operations teams can reconcile. Opus’s payments vocabulary includes card-message standards, real-time rails, settlement and tokenization. Each represents a place where a technically valid piece of software can still misunderstand the business.

Its competitive argument is specialization. Large consulting and technology-services firms also modernize banks; institutions can build internally, too. Opus pitches engineers who arrive knowing the domain. The proposition is fewer misunderstandings between the people describing a payment problem and the people writing its solution. Whether that advantage holds depends on the team and the engagement.

A translator with three jobs

In May 2024, Opus introduced Paysemble, a framework built around three layers: a message translator, a workflow orchestrator and an interface module. The names are wonderfully literal. Translate the instruction. Decide what happens next. Connect to the system that must act on it. Configurable workflows cover use cases including retail, real-time and cross-border payments.

The framework uses cloud and microservices architecture and is designed to fit existing infrastructure. For a buyer, the attraction is reusable groundwork. A new connection need not begin with a blank screen. But the surrounding work still matters: security requirements, message mapping, network testing and the peculiarities of the institution receiving the software.

“Continuous product development and testing consume a large volume of resources”

Praveen TM, then Opus CEO, at Paysemble’s launch

Opus’s business model follows that practical reality. It sells consulting and engineering engagements, including longer transformation programs, rather than a consumer payment app. Its own frameworks support the work. Buyers are purchasing implementation expertise as well as code, with responsibility stretching beyond the first demonstration and into systems that people depend on daily.

Give AI a smaller assignment

FinGeniusAI arrived in January 2024 with three initial use cases: intelligent payment routing, cash-flow forecasting and payment enrichment with automatic repairs. These are bounded jobs. Routing selects a path. Forecasting anticipates a need. Enrichment repairs or supplements payment information so that processing can continue. Each gives a buyer something concrete to evaluate.

In a 2024 interview, then CEO Praveen TM described the adoption barriers: scarce expertise, large investment requirements and uncertain returns. Opus proposed limited-budget proofs of concept with customers and partners. The commercial logic is straightforward. A finance team can assess an operational improvement more readily than an open-ended promise to transform the institution.

The emphasis has since widened. Srini Rajamani became CEO in January 2025, succeeding Praveen. By June 2026, Opus was describing a Databricks partnership aimed at fraud operations, dispute management and payments intelligence. The partnership’s stated starting market was North America. Its premise connects data infrastructure with specific financial workflows, extending the same preference for a defined operational job.

The people who remember the old system

There is a human counterpart to this engineering pitch. Opus’s careers material emphasizes mentoring and continuous learning. Its India entity describes its values with the acronym RICE: Respect, Integrity, Collaboration and Entrepreneurship. Great Place To Work lists it among India’s Best Workplaces for Women 2024. In a business selling accumulated knowledge, how people learn and stay matters.

Outside client work, its Project Shiksha scholarships offer a different time horizon. In July 2026, Opus reported 20 graduates from the first cohort and continued support for 25 students for a sixth consecutive year. The detail is modest beside a technology announcement, but more tangible: students reached graduation after years of support.

For a prospective customer, the sensible starting point is equally concrete. Choose the payment flow that hurts. Map its dependencies. Agree what improvement means and which controls must survive the change. Opus’s most useful story begins there, with an organization learning how its own work gets stuck. The payment button can remain pleasingly simple because somebody has taken the complicated part seriously.