Markets Open
Global Markets
S&P 500 7,529.98 ▲ +0.6% DOW 52,520.39 ▲ +0.3% NASDAQ 26,094.94 ▲ +0.9% RUSSELL 2K 2,991.19 ▲ +1.2% VIX 16.13 ▼ -4.6% GOLD 4,139.8 ▲ +1.7% CRUDE OIL 72.03 ▼ -2.0% EUR/USD 1.14 ▲ +0.3% BTC 62,842 ▲ +1.9% ETH 1,738.96 ▲ +1.0%
Fintech

Softjourn executive urges broader scrutiny of fintech developers

Sergiy Fitsak says fintech firms often underweight regulatory execution, crisis planning and exit terms when choosing technology partners.

Ingrid Halvorsen

By Ingrid Halvorsen · Staff Writer

· 3 min read

Fintech companies risk exposing themselves to compliance failures, security weaknesses and costly technology debt if they select software development partners mainly on engineering credentials, according to Sergiy Fitsak, managing director and fintech expert at Softjourn. In an external opinion published by Finextra, Fitsak argued that vendor reviews often miss the operational and contractual issues that determine whether a long-term technology relationship holds up under regulatory pressure.

Fitsak said technical competence should be treated as an entry requirement, not the deciding factor. He identified three areas that deserve closer attention in fintech procurement: practical command of regulation, readiness for incidents and staff changes, and contract language covering intellectual property and termination.

Compliance as an engineering constraint

According to Fitsak, many development providers describe themselves as familiar with fintech compliance because they know the names of major regimes such as PCI DSS, GDPR and SOX. He said the more important test is whether a provider can show how rules affect design choices, including cloud settings under PCI DSS 4.0.1, contractual obligations on third-party providers under DORA, and access-control design linked to the expanded multi-factor authentication requirements in NYDFS Part 500.

His argument is that architecture in financial technology often has direct regulatory consequences. Decisions about environment separation, user permissions, log retention and third-party dependencies can become compliance positions once a system goes live. A development team that does not account for those constraints during build-out may leave a fintech company with problems that emerge later in production, Fitsak said.

He suggested that fintech buyers should move beyond asking whether a vendor knows the applicable rules. In his view, the stronger test is whether the team can describe a past case in which a regulatory requirement changed an architectural decision.

Incident response and continuity

Fitsak also said vendor assessments frequently give too little attention to what happens when systems fail or data is exposed. In financial services, he said, production incidents can trigger more than engineering work: downtime and data exposure may create regulatory reporting duties, fines and reputational harm.

He pointed to several issues that buyers should examine, including escalation speed, named contacts during a crisis, the structure of post-incident reviews and whether a provider has rehearsed a breach scenario. A written response plan alone may not be enough if it has not been tested, according to Fitsak.

Continuity of personnel is another risk in extended development engagements, he said. If a senior engineer leaves after gaining detailed knowledge of a client’s codebase, the client needs to know how that knowledge is preserved and transferred. Without a structured process, Fitsak said, the risk moves back to the fintech company.

Exit rights and ownership

Contract provisions can become expensive when a development relationship ends, Fitsak wrote. He said procurement teams often focus on price, schedule and scope while giving less attention to intellectual property assignment, data handling at termination and knowledge-transfer obligations.

For fintech companies, Fitsak said ambiguity around ownership can carry practical consequences because algorithms, business logic and compliance-related system design may hold competitive value. He cited contracts that grant ownership of deliverables while limiting reuse with later partners, confidentiality provisions that sit only at company level rather than with individual team members, and termination terms that do not spell out knowledge-transfer duties.

Fitsak concluded that fintech due diligence usually captures basic engineering capability but can fail on less visible questions. In his assessment, the strongest vendor reviews test whether a partner understands the regulatory stakes of the product, has a practiced response when problems occur and has agreed contract terms that protect the client when the engagement ends.

This story draws on original reporting from Finextra Research.

More from Fintech

All Fintech →