FinTech is an integral piece of the technology and business stack of most financial services firms. Complexity can range from simple tasks like monthly data updates to mind-bending complexity such as full-service middle and back office functionality.
In this article, we’ll address the most common causes of failure for the high-risk, high-reward complex offerings.
1. Stale static data updates
Of all the reasons for failure, this one is the easiest to fix. Before production implementation, there’s often a need to update customer accounts, securities, account mappings, or other static data. It amazes me how often clients submit this information using stale data.
One of two mistakes often occur.
The client may take a save of the static data on a Monday prior to implementation weekend, but additional data additions or other changes occur during the week leading up to the go-live, resulting in missed updates.
The other problem I’ve seen occur is the client inadvertently sending an outdated list of data items to update. This problem occurs because there are often several tests or mock upgrades before the real thing. The ones responsible for collecting the required data mislabel the files or don’t include a date, so they inadvertently send the wrong file. It might sound comical, but it does happen.
In either case, when go-live finally comes and transactions start flowing, someone will notice missing items, downstream functions not receiving the data they need, or updates failing to occur.
The solution is simple. Label files with dates to avoid inadvertently using an outdated file. Second, wait until the Friday before go-live to pull your final list of accounts to update, or at the very least, run a final assessment of this data to ensure any late additions to the production environment get proper updates.
2. Disconnect between the test team and the front office
Most firms have dedicated teams to test and validate applications or services before handing off the system to the day-to-day users. This approach makes sense as the day-to-day users spend most of their time running the business.
Still, it’s not uncommon for the test team to give their blessing only for the users to give it a whirl and complain that it’s not what they expected or it doesn’t meet their expectations.
Firms can avoid this problem through robust elicitation of requirements and translation into detailed test cases that capture not just the default (happy path) scenarios but also the exceptions that might occur. There’s no easy way to do that other than leveraging existing process assets to build cases, conducting iterative test cycles, capturing production issues to include in future testing, and working with your vendor to identify scenarios you might have missed.
3. Aggressive timelines with no slack
Whenever you embark on an onboarding or major implementation project, always ask to see the SOE (sequence of operations) or the project plan. If there’s no slack in the schedule, you’ll miss your date. Shit happens. It always does. Even with the best of preparation, the most professional of project managers, the most knowledgeable subject matter experts, and dedicated people, problems will arise. Over long projects people get sick, leave organizations, or change jobs. Priorities shift. Technology fails. Third-party service providers don’t meet their timelines. A stakeholder questions a flow or feature and grinds the project to a halt. I could go on for hours describing all the reasons why projects get delayed even when first-class people run them.
Bottom line.
A project schedule must include buffers or slack to account for the unknowns and more importantly, the unknown unknowns.
4. Accepting issues that should be fixed before going live
Issues often arise during testing. The client and vendor must determine the severity of these issues and whether they must be addressed before go-live or if reasonable workarounds exist to allow for the schedule to continue unimpeded. In the latter situation, the respective teams will agree on a date to deliver the fixes or gaps post-production.
The vendor wants you to go live as soon as possible to start collecting revenue. The client wants to go live to start realizing the benefits of the new service and to move on to other projects. That said, they both have an interest in ensuring the system is ready on day one. The vendor wants to avoid the chaos of fixing critical post-production issues and, of course, wants to avoid the reputational damage of an implementation gone wrong.
The client faces reputational risks with their customers as well as financial risks when major systems fail. It’s imperative for both the client and vendor to look at the big picture and be honest about the severity of an issue. Better to delay the schedule a few weeks than risk a financial and reputational calamity to meet a date.
5. Lack of a complete ecosystem design to uncover dependencies
On one of the first implementations I worked on, back when I had relatively minor responsibilities, a major broker deal went live, and for several weeks after experienced hundreds of daily breaks in their books and records that had to be manually resolved.
It was a literal nightmare.
What was the cause? The client failed to consider several downstream systems during the solution design phase, and worse, did not include these systems in their end-to-end testing.
Whether you’re a client or provider of FinTech, you should develop a comprehensive design of your entire ecosystem, inclusive of dependencies, leverage points, feeder and receiver systems, leakages, buffers, feedback loops, constraints, limiting factors, and triggering mechanisms. The process of creating this will take weeks, sometimes months if they’re particularly complex, but it’s worth it.
Once you have a complete design, you can identify all the affected systems, sub-systems, and processes. This step will allow you to identify any gaps and generate appropriate test cases for all downstream and upstream systems.
6. Underestimating integration complexities
One of the most challenging aspects of FinTech implementation is integrating vendor systems with existing ones in your organization. There is often data exchange to be considered, conflicting data structures to be reconciled, development efforts to address inefficiencies and gaps to identify, and technology incompatibilities to rectify.
Add to that, the human element of teams working together who may have different processes, organizational cultures, and priorities.
To mitigate the integration risk, organizations should identify all points of integration as early as possible, dedicate separate streams and personnel to address needs, develop a robust SIT phase (system integration testing), and assign a leader from the client organization to champion the effort. To get this part right, you need more than just a solid process, you need a leader who can effectively manage a cross-functional and cross-organizational team.
7. Client competing priorities
In the midst of a complex conversion, the client informs the vendor representative that the accounting team needs the region for a few days to do whatever it is they need to do. Those few days pass only for the client to mention that the accounting team didn’t quite get to do what they needed, and so a few more days will be needed.
A project can handle one or two of these delays. In some cases, the vendor can use it as an opportunity to deliver fixes to the software. But when it becomes pervasive, these competing priorities will destroy the project timeline.
The lead on the client side who controls access must take a ruthless approach to protect the project team from interruptions to their flow of work and from competing priorities that derail the timeline. At the very least, they must make it clear to their stakeholders the impact of these disruptions, not only the delays to the team but also the lost productivity of task switching.
8. Client disengagement
Vendor project leaders are all too happy to let a project slide at the first sign of client disengagement. It’s not because they don’t want to do a great job, but instead because of another client who’s hounding them about their project. And so, if the client disengages, the vendor uses it as an opportunity to put out fires somewhere else.
If you’re a client, you need to make it clear that the vendor is always being watched. If a status dashboard doesn’t arrive on time, inquire about it. If task updates aren’t coming, call for a meeting to discuss.
In short, you want to make use of the Hawthorne Effect, which states that people behave differently when they know they’re being watched. If people sense you’re not watching, they’ll shift their efforts towards someone who is.
9. Failure to maintain organizational process assets
Have you ever encountered a problem, fixed it, and then suffered through the same problem six months or a year later? It’s okay. You can admit it. It’s happened to everyone at least once.
For organizations working with complex systems, it’s essential to look at your processes of ensuring excellence as an endless iterative cycle of improvements. In practice, this means recognizing errors and inefficiencies in your processes, finding the root causes behind them, determining and implementing a solution, and incorporating corrective actions into your standardized practices to ensure that the same problem does not repeat in a future project.
Too often, when clients and even vendors encounter a problem, they settle on a quick solution to address the symptom and fail to identify or solve the root cause. Even if they do solve for the root cause, due to the pressures and chaos of the moment, either team leaders neglect to incorporate these changes into future processes or they lack the organizational discipline to do so.
10. Vendor incompetence
Yes, it happens. Sometimes, a new project lead is running your project. Other times, your vendor just may not have their act together, especially when it comes to new products. Clients sometimes think of the FinTech provider as merely flipping a few switches to set up their environment. It’s always more complicated than that.
For clients, it’s essential to assess the vendor’s implementation competency at the outset of the project.
First, ask to see their project plan or SOE (sequence of operations). It should be extremely detailed and specific. The tasks need to be broken down to a level where someone with minimal skills can execute them without interpretation or assumptions. It helps to have someone on your team with vendor experience to assess this.
Here’s an example.
Bad → “Execute database creation scripts”
Good → “Pull the execute database creation scripts ‘ABC_client_database_creation.db’ from location /anylocation/client/db/creation_scripts/ and use wrapper XYZ from location /anylocation/client/db/creation_scripts/wrapper/ and execute the wrapper in dbexecute tool in region <insert client region>.
The more detailed the tasks, the less likely someone needs to assume or interpret, reducing the chances of errors.
A lack of a detailed plan is, in fact, incompetence. Hopefully, if you are the client, you will have done your due diligence prior to signing the contract. If not, and if you find your vendor in this position, you will need to devote more resources to the project and put additional pressure on vendor senior management to address issues as they arise and ensure timely resolution.
11. Bonus - Third-party delays
Number eleven is included as a bonus. It’s the one where you exert the least control over the outcome.
For some projects, it’s a vendor and client relationship. For most, however, you will have to work with third parties: settlement depositories, clearing agencies, data providers, technology providers, regulatory authorities, and others.
The key to limiting this risk lies in your ability to meet whatever requirements are set forth in third-party contracts on a timely basis and in building exceptional relationship management. I’ve been involved in a few onboarding projects where the implementation ground to a halt while we awaited industry or regulatory signoff. The client had provided all the required documentation. We, as the vendor, had met all our requirements, yet the signoff sat on someone’s desk. In some cases, either we or the client had someone at our respective organization who could make a phone call and expedite the process. In other cases, we simply had to wait.
Both the client and vendor should approach third-party relationships with the same care as they do client relationships. A healthy relationship between organizations can resolve beurocratic bottlenecks.