Nikita Cunskis
CUNSKIS

Scalable platforms for commerce & AI

Senior engineering and technical ownership for ambitious digital products.

Discuss your project

FinTech: the code that moves money has to be right every time

I work where a mistake is not a bug report but a regulator’s letter — inside an FCA-authorised consumer-credit platform, on the decisions that approve, schedule and collect money.

As a senior backend engineer at Vuelo, a Buy-Now-Pay-Later platform for travel, I am one of seven engineers and own two areas: fraud prevention, the checks that decide whether an application and a payment are genuine, and the search engines that power the travel side of the product. Both have to be right on every request and explainable months later.

What do I actually understand about money software?

  • Fraud preventionThe layer between an application and a decision: signals, thresholds, provider failover and an audit trail that explains every outcome. It has to block the wrong applicant without slowing down the right one.
  • Search that answers in millisecondsThe travel side of a BNPL product is a search product: availability, pricing and ranking across suppliers, with results that have to be correct, fresh and fast under load.
  • Customer outcomes and regulationFinancial-hardship flows, operations review queues gated by permissions, redaction of personal data in logs, decisions that can be reconstructed months later. I design for the conversation with the regulator before it happens.
  • Integrations that must not fail quietlyCredit bureaus, card processors, banking-as-a-service providers, partner reporting feeds, CRM event platforms. Automated credential rotation, explicit timeouts, structured error semantics, sandbox routing for QA — so that a third party’s bad day does not become your customers’ bad day.
  • Reliability under loadQueue semantics, retry storms, idempotency, jobs that must not overlap. When something breaks in production I write the root cause, the blast radius and the verification plan before the fix — because in finance the explanation is part of the deliverable.
  • Discipline that scalesStrict code standards applied across large diffs, tests as part of every change, and every sizeable feature shipped with a written scope lock and a QA window. In a regulated product, discipline is the feature.

Why does this matter to you?

  • Fewer production incidents in the part of the system that costs the most when it fails
  • Compliance conversations you can walk into with evidence, not apologies
  • Features delivered across core, API and back office by one accountable engineer
  • Honest assessment of risk — including when a shortcut will cost more than it saves

What can I do for your product?

  • Design or rebuild a credit-decision or verification engine with provider failover and full explainability
  • Fix instalment, refund and reconciliation logic on a live book without stopping the business
  • Integrate credit bureaus, card processors, banking-as-a-service and partner reporting the resilient way
  • Build forbearance, audit and operations tooling that satisfies the regulator and the ops team at once
  • Rescue a platform from queue, retry and consistency problems — with a written root cause

How do I work inside a regulated team?

At Vuelo I am one of seven engineers, on contract, remote from Riga. Every change I make goes through a written scope, a pull request reviewed by a colleague, a QA window and a release note that the compliance side can read. When something breaks in production I write the root cause, the blast radius and the fix before the fix is merged. That discipline is slower per ticket and much faster per quarter, because nothing has to be done twice under a regulator's deadline.

What does a FinTech engagement with me look like?

Three shapes have worked: a senior engineer embedded in your team for a module that has to be right (decisioning, fraud, reconciliation, a bureau or processor integration); a rescue of a live system with queue, retry or consistency problems, delivered with a written root cause; or a fractional CTO role for a lending product that does not yet have a technical owner. In all three I quote after a 30-minute call, and I say no to work I would not put my name on. Fractional CTO.

Building or fixing a lending, payments or BNPL product?

Tell me where the money flows and where it hurts. You will get a direct opinion on the risk, the fix and whether I am the right person for it.

Discuss your project