Markets Open
Global Markets
S&P 500 7,492.17 ▼ -0.6% DOW 52,858.78 ▼ -0.4% NASDAQ 25,772.06 ▼ -1.3% RUSSELL 2K 2,980.14 ▼ -1.0% VIX 16.34 ▲ +4.9% GOLD 4,119.6 ▼ -0.9% CRUDE OIL 72.25 ▲ +5.4% EUR/USD 1.14 ▼ -0.2% BTC 63,711 ▼ -0.1% ETH 1,787.82 ▼ -0.4%
Fintech

Mbanq engineering executive urges banks to rethink enterprise architecture

Igor Kostyuchenok says bank architecture teams should work closer to engineers and prove designs in production before setting policy.

Ingrid Halvorsen

By Ingrid Halvorsen · Staff Writer

· 3 min read

Mbanq SVP of Engineering Igor Kostyuchenok has argued that banks face avoidable operating cost and delivery risk when enterprise architecture is run as a governance function separated from engineering. In a Finextra community opinion piece, he said application sprawl creates integration, security, vendor, compliance, licensing and engineering burdens, and that architecture choices should be tied to outcomes such as faster product delivery, lower transaction costs, stronger risk controls and improved customer experience.

Finextra identified the post as external content supplied by the author and published without editing, reflecting the author’s views. Kostyuchenok, who is based in Munich, said many large banks maintain enterprise architecture teams, but argued that their diagrams often fail to match the systems running in production.

Architecture as engineering practice

Kostyuchenok’s central argument is that enterprise architecture should be treated as an engineering discipline rather than a document-review process. He said architecture groups that sit outside delivery teams and approve designs through presentations can produce models that appear orderly but do not hold up when implemented.

He argued that architects need direct exposure to the teams operating core banking platforms. Without that, he said, they may miss fragile integrations, weak data models or deployment processes that take many hours and depend on manual intervention.

In Kostyuchenok’s view, effective architects work with engineering teams, inspect code and form their design decisions around constraints found in live systems. He contrasted that with relying on generic reference models or vendor materials that may not reflect a bank’s operating conditions.

Production proof before policy

The opinion piece also challenged banks to validate architecture choices before requiring broad adoption. Kostyuchenok said a proof of concept using synthetic data or a laptop environment does not show whether an architecture can handle live transaction volumes, failover requirements or compliance scrutiny.

That distinction matters in banking technology because production systems must meet availability, security and audit expectations that go beyond early demonstrations. Kostyuchenok said architecture decisions should be backed by engineering data from real systems before they are converted into organisational rules.

He linked that approach to credibility inside technology organisations, arguing that architects who test ideas against operating evidence are more likely to win support from delivery teams than those who issue standards based on theory.

Application costs and business value

Kostyuchenok said banks should treat every additional application as a recurring cost, not only as a functional gain. He listed integration points, security exposure, vendor oversight, regulatory obligations, software licensing and continuing engineering time among the burdens attached to each system.

On that basis, he argued that architects should seek to make fewer applications serve more functions, and that any new system should face a higher bar than keeping the current setup. He did not provide figures on application counts or costs in the post.

The author also said architecture decisions should be linked to measurable business value. He cited faster time to market, lower cost per transaction, better risk management and improved customer service as examples of outcomes that can justify technical choices.

Leadership and decision-making

Kostyuchenok also addressed how architecture leaders run discussions. He said senior architecture executives who state their view first can discourage junior architects or engineers from raising objections, including warnings about production failures.

He argued that heads of architecture should hear alternatives and operational concerns before making a decision. His conclusion was that enterprise architecture works when architects sit close to engineering teams, test designs in production, count the cost of applications and connect technology choices to banking outcomes.

This story draws on original reporting from Finextra Research.

More from Fintech

All Fintech →