Senior programme leadership and strategic advisory for financial institutions — from card portfolio migrations and regulated market entry to digital transformation and compliance programmes. Not a large firm with a junior team. One experienced practitioner, present throughout, who has spent 20 years at the intersection of business and technology inside real banks.
"Most transformation programmes don't fail because of technology. They fail in the space between what the business intended and what technology delivered — and nobody in the room could bridge that gap."
I have spent my career in that space. Starting as a business analyst inside a bank, progressing through project management, programme direction, and solution architecture — I understand both what a product owner or head of operations actually means when they describe a requirement, and what that implies at a systems level. That dual perspective is rare, and it is the single most important factor in whether a transformation programme delivers what it promised.
NPROCONSULT was founded in 2018 on a simple premise: the best advisory comes from someone who has been on the inside. With over two decades spanning cards and payments, retail banking, commercial banking, and private wealth management, I bring domain knowledge that most consulting firms cannot offer.
My career began as a business analyst at a major European bank in 2003 — where I learned that transformation succeeds or fails not in the boardroom or the data centre, but in the quality of understanding between them. I have since held every role in that chain: BA, project manager, programme director, solution architect, and product owner. That breadth means I can speak credibly to C-suite sponsors and technical architects in the same day — and translate between them when the gap starts to show.
Beyond programme leadership, I have end-to-end experience across the full procurement and vendor lifecycle: from the initial Request for Change through requirements definition, RfP design and management, vendor shortlisting, commercial and legal negotiation, and contract alignment. I have led both onsite and offshore delivery teams across multiple geographies simultaneously, managing the coordination, quality, and accountability challenges that come with distributed delivery. And I communicate with equal fluency at every level — from developers and architects to board-level sponsors — which means the right information reaches the right person, in the right language, at the right time. Based in Luxembourg, with engagement experience across Switzerland, the Nordics, DACH, the UK, Belgium, Portugal, Ireland, and the UAE.
"I can walk out of a requirements workshop with a product owner in the morning and into a technical architecture review in the afternoon — and be equally effective in both rooms."
When a business stakeholder describes a requirement — whether it's a product owner, a head of operations, or a compliance officer — there is what they said, what they meant, and what they actually need. The gap between those three things is where most programmes accumulate technical debt, stakeholder frustration, and budget overruns. My role is to close that gap before it opens.
Having worked as a business analyst, project manager, IS auditor, and solution architect, I understand how decisions made in business requirements meetings cascade into architectural choices — and how architectural constraints need to be translated back into expectation management with the business.
The result: stakeholders receive what they asked for. Not a technically correct interpretation. What they actually needed.
In 2023 I founded APIDNA — an agentic AI platform designed to automate complex enterprise workflows for regulated organisations. My advice on AI adoption in financial services is not theoretical. I understand what it takes to build production-grade AI systems, what the real integration challenges look like, and how to manage expectations of business stakeholders who have heard many AI promises.
For financial institutions exploring AI-enabled operations — whether in payments processing, compliance monitoring, client onboarding, or back-office automation — I offer the rare combination of financial services domain depth and hands-on AI platform experience.
Explore APIDNANo pitch. No proposal before we've spoken. If you're working on a complex financial services transformation and want a senior perspective from someone who has done this work at this level, I'm happy to talk.
Your details will only be used to respond to your enquiry and will not be shared with any third party. By submitting you agree to our Privacy Policy.
Last updated: January 2025
NPROCONSULT (operated by Nikolay Prokopiev, Luxembourg) is committed to protecting your personal data in accordance with the EU General Data Protection Regulation (GDPR).
Data Controller: NPROCONSULT · Nikolay Prokopiev · Luxembourg
Contact: nikolay.prokopiev@nproconsult.com · +352 661 737 346
When you submit the contact form on this website, we collect:
We do not collect data through tracking cookies, analytics platforms, or advertising networks.
Your data is used solely to respond to your enquiry and to communicate with you about the services you have expressed interest in. We do not use your data for marketing, profiling, or automated decision-making.
We process your data on the basis of legitimate interests (responding to your business enquiry) and, where applicable, your consent (as indicated at the point of submission).
Contact form submissions are delivered via Web3Forms to our email address. We retain correspondence for no longer than 3 years from the date of last contact.
This website uses only a single functional cookie (npc_cookie_v1) to record that you have acknowledged our cookie notice. This cookie contains no personal data and is not used for tracking or advertising. No third-party cookies are set.
Under the GDPR you have the right to: access your data, request correction or erasure, object to processing, and lodge a complaint with your national data protection authority. To exercise any of these rights, contact: nikolay.prokopiev@nproconsult.com.
We may update this policy from time to time. The current version is always available at nproconsult.com.
This website uses only essential functional cookies — no tracking or advertising. Cookie settings · Privacy Policy
We use cookies to ensure the website functions correctly. No advertising or tracking cookies are used on this site.
Required for the website to function. Stores your cookie preference. Contains no personal data.
Currently none are used. If analytics are added in future, they will only be activated with your explicit consent.
Most programme post-mortems blame the technology. The real failure almost always happened earlier — in the space between what the business meant and what IT understood. And because nobody was translating, nobody noticed until it was too late to fix cheaply.
There is a moment in most transformation programmes — usually somewhere between requirements sign-off and the first technical design review — where the two sides of the table start talking past each other. The business team believes the requirements are clear. The IT team believes they are building what was asked for. And nobody in the room has the standing, or the language, to tell both of them they are wrong.
This is not a communication problem in the way that word is usually meant. It is not solved by more meetings, better documentation, or a RACI matrix. It is a structural problem: the people who understand the business outcome and the people who design the technical solution are rarely the same people, and the handoff between them is where requirements quietly transform into something else.
When a business stakeholder describes a requirement, they are describing an outcome — what they want the world to look like when the programme is done. When a solution architect interprets that requirement, they are designing a system — what the technology needs to do to produce that outcome. These are different questions, and answering one does not automatically answer the other.
The gap is not in what is written. It is in what is assumed to be obvious on both sides — and never said.
A product owner says they need "real-time visibility of transaction status across all channels." To them, this means a dashboard a relationship manager can open during a client call. To an architect, this means an event-streaming platform, a unified data model, and a real-time API layer. Both are correct. Neither is complete. And unless someone is asking both parties what they actually mean — and translating in both directions — the system that gets built will be technically correct and operationally useless.
This plays out differently across programme types. In regulatory programmes, compliance teams describe obligations in legal language that engineers cannot implement directly — and the translation step gets skipped because everyone is under deadline pressure. In platform migrations, business users describe current-state processes without knowing which parts are enabled by technical workarounds that will disappear in the new system. In vendor selection, requirements are written to satisfy an RfP template rather than to actually specify what the organisation needs — and the vendor who wins is the one who answered the question asked, not the question that mattered.
The organisations that navigate this well do not have better technology or better processes. They have people in the room who are fluent in both languages — who can sit with a head of operations in the morning and understand the business logic behind a requirement, and then sit with an engineering team in the afternoon and understand what that requirement means for the data model, the integration architecture, and the testing approach.
That fluency takes time to develop. It requires having worked on both sides of the table — not sequentially, but simultaneously, on programmes where the consequences of getting the translation wrong were visible and real. It is not something that can be substituted with a business analyst who writes requirements or a project manager who facilitates meetings. It requires someone who genuinely understands both worlds and is accountable for the gap between them.
Before a programme starts, the translation layer should be a named role with a named person — not an assumed outcome of good process. That person should be present in business workshops and technical design sessions. They should be the one who notices when a requirement has been interpreted differently by different parts of the programme. And they should have the authority to call a stop when the gap has grown too large to close without going back to the business.
Most programmes budget for project management and technical delivery. Very few budget for translation. That is where the money gets lost.
Card migrations are consistently underestimated — not because the technology is unpredictable, but because the dependencies between scheme certification, data migration, and business readiness are poorly understood at the start. The surprises are almost always the same surprises, on every programme.
The initial project plan for a card portfolio migration is almost always built around the data migration. Move the cardholders, move the accounts, move the transactions. Stand up the new platform, run parallel processing, cut over. Six to twelve months, depending on volume.
This plan is wrong — not because the data migration is underestimated, but because the data migration is only one of four things that have to happen simultaneously, and the other three are poorly understood by the people who wrote the plan.
A card portfolio migration involves four interdependent workstreams. The problem is that they are typically run by different teams, with different reporting lines, who only start coordinating properly when one of them is blocking another — which is always later than it should be.
Data migration is the one everyone plans for. Cardholder data, account data, transaction history, tokenisation records, digital wallet registrations. The technical complexity here is real, but it is knowable at the start. The surprises come from data quality issues that were not identified in the initial assessment — cards in states that don't map cleanly to the new platform, tokenised cards where the token vault migration was not scoped, historical transaction data in formats the new system cannot ingest.
Scheme certification is the one that most often blows the timeline. VISA and Mastercard certification processes have fixed windows, fixed test environments, and fixed lists of test cases that must pass before go-live approval is granted. The certification timeline is not negotiable — the scheme will not accelerate it because the project is late. This means that if scheme certification is not started early enough, it becomes the critical path regardless of how well everything else is going. Starting it early requires knowing exactly which products and transaction types are in scope, which requires the data migration analysis to be further along than it usually is at that stage.
Business readiness is the one that is most often treated as an afterthought. The operations team, the customer service team, and the relationship managers who handle day-to-day cardholder queries all need to be trained on the new platform and new processes before go-live — not after. Card migration go-lives that happen on time technically frequently fail operationally because the business was not ready. The volume of cardholder queries in the first week after a migration is always higher than expected, and if the people handling those queries do not know the new platform, the go-live becomes a crisis.
Cardholder communication is the one nobody wants to own. New card numbers, new PINs, updated tokenisation for digital wallets, changes to the self-service portal — all of this requires a coordinated communication programme that has to be timed precisely against the technical go-live. Too early and cardholders are confused before anything has changed. Too late and they are already calling. The communication plan also has regulatory requirements in most jurisdictions that add lead time which is rarely factored in at the start.
The card migrations that land on time are not the ones with the best technology or the most experienced engineers. They are the ones where all four workstreams are mapped and sequenced from the beginning, with explicit dependencies identified between them — and where a single person is accountable for the critical path across all four, not just within each one.
The scheme certification window is fixed. Everything else has to be planned backwards from it — not the other way around.
The second thing the good programmes do is invest in data quality assessment before the timeline is set. The surprises in data migration are not random — they are predictable if someone looks at the data carefully enough before the project plan is signed off. That assessment takes time and resource, and it is almost always deprioritised in the early stages when everyone is focused on getting the project started. It is always cheaper to do it before the plan is fixed than to discover the issues six months in.
For a portfolio of up to two million cards with a clean data set and a clear scheme certification scope, nine to twelve months is realistic if all four workstreams start in parallel from day one. For larger portfolios, or portfolios with significant data quality issues, eighteen months is not unusual. Programmes that plan for six months and do not find the issues until month four do not recover — they run late, they cost more, and the go-live quality suffers.
The right answer on timeline is the one that comes from actually looking at the scope, the data, and the certification requirements before the plan is written. Not the one that fits the budget cycle.
Regulatory programmes have a fixed deadline and a non-negotiable definition of success. That clarity should make them easier to deliver than other transformation programmes. In practice, the consequences of getting the fundamentals wrong are much harder to recover from — and the stall points are almost always the same.
Most transformation programmes suffer from scope creep, shifting priorities, and deadlines that move when delivery pressure builds. Regulatory programmes do not have this problem. The regulator sets the date, the regulator defines what compliance looks like, and being late or being non-compliant are both unacceptable outcomes.
This clarity is an asset — it forces prioritisation, it removes the ambiguity about what done looks like, and it creates genuine organisational urgency. It is also a risk, because it creates pressure to start delivering before the programme is properly set up. The urgency to show progress to the regulator, to the board, and to internal stakeholders often pushes programmes into delivery mode before the foundations — requirements, architecture, and governance — are solid enough to build on.
The first place regulatory programmes stall is in the translation from legal obligation to technical requirement. A compliance team that understands the regulation deeply will produce a requirements document that is legally accurate and technically unimplementable — not because they are wrong about the regulation, but because legal accuracy and technical implementability are different things, and producing both requires a different set of skills than either alone.
The result is an engineering team that receives requirements they cannot build, and responds in one of two ways: they build something adjacent that satisfies the letter of the requirement but not the intent, or they raise a blocker that escalates up the chain and stalls the programme while the compliance and IT teams negotiate what the requirement actually means. Both outcomes are expensive. The first one produces a compliance risk. The second one loses weeks.
Legal accuracy and technical implementability are different things. Producing both requires someone who is fluent in both languages.
Regulatory programmes almost always discover, partway through delivery, that the data required to demonstrate compliance does not exist in the form the regulator expects. Transaction records that need to be enriched with additional attributes that were never captured. Customer data that exists in multiple systems with no single source of truth. Audit trails that were not designed to support the level of granularity the regulation requires.
These discoveries are not surprises in the sense that they could not have been predicted. A proper data assessment at the start of the programme — mapping what the regulation requires against what the organisation actually holds, in what form, and in which systems — will surface all of them. That assessment takes time and requires access to systems that are not always easy to get access to quickly. The pressure to start delivering means it is often skipped or compressed. The cost of skipping it is always higher than the cost of doing it.
The third stall point is governance. Regulatory programmes require decisions — about scope, about technical approach, about what level of compliance is sufficient in cases where the regulation is ambiguous — and they require those decisions to be made quickly and with authority. Programmes that route every significant decision through a committee that meets monthly, or that cannot get a decision without sign-off from stakeholders who are not close enough to the programme to decide quickly, will stall.
The governance structure for a regulatory programme needs to be designed around the decision velocity the programme requires — not around the organisation's standard project governance framework. That means named decision-makers with genuine authority, a clear escalation path for decisions that cannot be resolved at working level, and a steering committee that meets frequently enough to unblock issues before they become critical path delays.
What connects all three stall points is that they are all set up in the first four weeks of the programme — in the way the requirements are written, in whether a data assessment is commissioned, and in how the governance is designed. By the time they manifest as visible problems, the programme is already months in and the regulatory deadline is closer. Recovering from any of them at that point is possible but expensive.
The programmes that deliver on time are not the ones with the most resource. They are the ones that invest in getting the foundations right before they start building on them.