Guide to Working with Financial Technology Vendors

The financial services industry is becoming increasingly dependent on technology. One might even argue that financial firms are becoming technology firms. 

The pace of change in the technology world is relentless – new vendors with innovative solutions are appearing all the time. It’s a full time job just to keep up with it.

It is increasingly important for leaders in financial services firms to be well versed in technology so they can make informed decisions about buying vs. building technology solutions, choosing the right partners and, most significantly, realizing a positive outcome or return in a timely manner.

I’ve encountered these issues over the past two decades with a wide variety of clients, prospects and partners – and I’ve learned a few things along the way. As a technology vendor, my success is tied to the success of my clients and business partners. With this in mind, I have assembled some key insights to help guide you to make better technology decisions for your company.

 

Big, stable vendors vs. small, nimble vendors

Should you partner with a large, well-established technology provider who will run a formal, structured project or a small, nimble firm with less structure but more ability to be agile? There’s no simple answer that applies to all situations.

Working with large firms has advantages – as well as drawbacks. It’s a mistake to assume that a large firm would have a better track record for project delivery than a small firm. Large firms may have a more evolved client engagement model, but they may also have difficulty innovating and moving as quickly as you need.  Formal processes also come with costs that can eat into your project’s return on investment (ROI).

Smaller technology firms can also be appealing to work with – they have lots of energy and you are often dealing with a senior leader or key decision-maker in the firm. But there are always questions: Does this small firm have the resources and skills to deliver? Do they have the capital to survive or will a competitor purchase them before your project is completed?  Do they have the discipline to deliver or will the ‘A’ team move on to the next exciting project before yours is complete?

Big and stable technology vendors are often viewed as safer choices (and, therefore, creating more job security) for decision-makers. But time-to-market has become such an important factor in this rapidly changing technology environment that it has complicated the decision-making process. Higher costs associated with larger firms may also make your ROI more difficult, whereas smaller firms that are quicker and often less expensive – making a positive ROI easier to attain but potentially adding an additional element of risk.

In the end, ask yourself this question: What type of firm will work best within your company culture and what are they key drivers to your project’s success?  Make sure to align these factors with your partners

If having a formal process with stage gates and formal reporting are important then go big, if you enjoy continuous change, constant flow of new ideas and lots of flexibility and you can sleep at night knowing that there is risk then go small.  

 

Financial terms need to be win-win

You want your technology vendor to make money. Too often, businesses are so focused on cost that they negotiate the vendor down to the point where the vendor isn’t making any money. You could not be making a bigger mistake.

You don’t want your vendor under financial pressure – you want them focused on creating your solution.

Understand a vendor’s cash needs and if you can’t afford the deal then don’t do it.

Aim to structure your financial model with your technology vendor as a win-win. Motivate the vendor so that if the project is successful then the vendor should also be successful. This can be achieved through some kind of variable compensation for the vendor on the measurable success of the project. For example, if the ROI results in cost savings, consider compensating the vendor on a portion of the cost savings, or if the ROI is new revenue consider giving the vendor a portion of that revenue.

Make sure you keep the cash flowing for your vendors so they can pay their bills, but as much as possible tie payments to milestones. Milestones need to be short sprints with measurable results, such as getting the first user live on the system. Clear milestones are best and there should be one senior decision-maker (not a committee) in your firm who decides if the milestone has been achieved. This individual needs to be close to the project (not, for instance a senior leader in a remote location) and motivated by project success.  Make your decisions quickly and if you do not feel the milestone has been met, tell the vendor exactly why and what they need to do to achieve the milestone.

Providing up-front funding is seen as a sign of good faith and technology vendors will feel more committed to your project. The risk, of course, is that you lose money in the project – but you really should not be entering into any arrangements if there is even the slightest concern or lack of trust.

Vendors hate holdbacks, because it is viewed as a lack of trust.  If you don’t trust the vendor, then don’t engage in the first place. You are better off to motivate your vendor with bonuses, not base compensation. It’s always a good idea to keep a reserve and, just like you would bonus a good employee, bonus your vendor – it doesn’t have to be a lot, but it contributes to the motivation they need.

 

“Partners” out-perform “vendors”

Vendors absolutely hate being classified as vendors. In our minds, it’s actually a derogatory term.

If you don’t consider your financial technology supplier a partner, then you should probably not engage. Here’s a great test – if you can’t call the CEO or primary project lead of your technology partner at home on the weekend, then you’re not dealing with a partner – you’re dealing with a vendor.

Make your technology partner a part of your business. Make sure your technology partner understands your business and the ROI for the projects they are working on. Set up a war room at your location exclusively for the project and have your milestones listed on the walls for everyone to see.

If you take meaningful steps to make your technology partner feel like part of your company, then they will be totally committed to the success of the project. And when that success comes, celebrate it with your technology partner.

 

 Try it. Shake your head to see the illusion.

Try it. Shake your head to see the illusion.

Beware of Powerpoint vaporware

This may seem like vendor bashing, but it’s not – because real technology partners can’t stand losing deals to firms that do a great job pitching a solution using a Powerpoint presentation.

I am constantly amazed by the excuses that vendors use to justify their use of Powerpoint presentations instead of live demos. It’s fine if they are up-front and honest that their system is still in development – otherwise you should expect to see a live demonstration of their technology solution.

If a vendor says they have a live working solution, but defer to a Powerpoint, then you should be concerned. Technology vendors are proud of their work and love showing it off. The problem you want to have is that you can’t get your prospective vendor to stop showing you how great their technology is.

Also, make sure to check the data in their demo, check for live URLs, look at the version and dates on the bottom of the screen, ask to see the demo on multiple occasions and ask for demos based on your actual use cases.  Don’t be afraid to ask for control of the keyboard and mouse and get them to direct you through the demo.

 

Manage your IT department

Vendors typically have a difficult relationship with corporate IT departments. IT professionals are proud of the work they do, but can often feel threatened by vendors and act defensively.

Your IT department will always think they can build a better solution internally because they know your systems and business best. They will come up with excuses as to why the external vendor’s solution cannot be integrated into your infrastructure. They may behave positively in front of the senior business people, but act differently when left alone with the vendor. 

It’s always a good idea to keep someone from the business side involved in conversations involving corporate IT.

Corporate IT can get frustrated because vendors come in and work on the cool stuff while they are left with maintenance of existing systems. It is critical that you line up your IT department to benefit from the vendor solution and a successful project.  Ideally, you get your internal IT department involved in the project, trained on the technology and working cooperatively with the vendor.  I have seen projects where the client lends a project manager (PM) to work on-site with the vendor.  The PM becomes part of the team and loyal to the success of the project and can act as a bridge between the client and the vendor helping to smooth over difficult situations. 

 

Working with Fintech entrepreneurs

Almost everyone is motivated by money, but fintech entrepreneurs are often more motivated by success – successful projects and new technology solutions that are put into market.

Recognizing the entrepreneur and putting them in the spotlight will help win their total commitment to the success of the project. Invite the entrepreneur to your corporate events and let them present to and provide updates to your senior executive team.

Participate in media releases and announce the partnership publicly. This further engages the entrepreneur and their professional reputation in the project since it becomes part of the public record, making success an even more important outcome.

Entrepreneurs are hungry for knowledge, so make sure they understand your business case and ROI – and that they understand the project success factors as well as you do. Also make sure they understand the impact of delays or failure.  They want to win, and they want you to win.

 

Security is not a contest, it’s a process

Security is a key topic in virtually every technology-based business that handles private client data or payment information. There are a number of ways you should be managing potential and existing vendors to ensure effective security systems and procedures are in place.

Ask priority vendors to provide you with the results of their most recent third-party security assessments. Security self-assessments are less reliable by themselves because they lack objectivity, but they can still contain helpful information. Security policies should be reviewed and assessments conducted on a regular basis, so ask your vendor about their practices in this area.

Due diligence should also include the vendor’s privacy practices and employee training programs. Privacy policies should be in place and the vendor’s staff should be receiving training on privacy policies and procedures.

Unless you’re in the business of IT security, you should consider having security audits of your vendors performed by a third-party security vendor.  This takes your IT team’s potential self-interest out of the equation. An IT team can easily kill a great project by making the vendor appear unsecure, because they simply want control of the project to remain internal. On the other hand, vendors can also pull the wool over the eyes of IT teams with slick talk and buzzwords – especially if your IT team is not made up of qualified security experts or they are not dealing with the latest technologies (which is often the case).

(As an aside, security assessments are not just for third-party vendors. You should also be putting your internal IT department through the same externally-led security assessments with the exact same rigor.)

As business leaders, you need to find the truth – especially when it comes to security. Don’t be afraid to award your technology partner the business when they fix any identified security shortcomings. 

Security is not a contest, it’s a process.

 

We do that today vs. We can to that

Perhaps the single most dangerous phrase you will encounter is: “Yes, we can do that.” As distinguished from: “Yes, we do that.” Listen carefully for it, because the difference is subtle, but critical. 

“Yes, we do that today,” means the feature you are asking about already exists in the current production version of the vendor’s technology solution.

“Yes, we can do that,” means the vendor’s technology in production likely doesn’t have the requested feature or functionality, but someone on their team can whip something together overnight and hack it into the production system to show you ASAP.

There is nothing wrong with partnering to build out new features, but make sure you know what you are buying and never under estimate the potential effort or impact of any changes. The small, simple things always seem to have the biggest impact.

If you are building a technology solution from scratch or adding on to an existing solution, it is imperative to first create a prototype that demonstrates the functionality and workflow before you start the actual development.  This will save you time and money in the long run and increase the chances of a successful project. 

The prototype should be reviewed with users to gather feedback, as it can be very useful in flushing out requirements to help all parties understand the project scope so they can properly size the project and effort required.  It still amazes me how often the tech team or even the business team is out of touch with what the end users need, so make sure to get some input as early in the process as you can.  

 

Customized solutions vs. adapting business processes

I have never met a client that doesn’t think they are somehow unique – their culture, business processes and organizational structure – and it’s true.  This leads many clients to assume that the vendor should customize their technology to meet their unique requirements. 

In some cases, customization makes sense. But in many cases, it is better in the long run for the client to examine their behavior and/or business processes and seriously consider altering them to accommodate the technological solution being considered.  This may sound unreasonable, but it makes sense on a number of levels.

Business processes are fluid and tend to evolve according to a number of criteria, some internal to the business (eg., leadership style, employee experience, culture, etc.) and others external to the business (eg., market changes, regulations, technology, etc.). When a business is considering a technological solution, it is typically a very good time to review business processes and determine what is necessary and what should be open for re-thinking and streamlining. This is an important part of the ROI for any technology upgrade.

On the other hand, the potential impact from customizations to a technology solution can be immense and it is important that all parties fully understand this impact. 

Creating customizations can be a nightmare for both vendors and clients.  Customizations often result in vendors having to maintain a separate code base – an iteration on the out-of-the-box solution that is customized to meet the client’s requirements.  This can drive up project costs significantly, especially when it comes to maintaining this separate code base and developing upgrades and enhancements over time. The vendor will be required run separate test cycles on the customized solution and all new feature development needs to be applied to both the core product systems and your customized solution.

Vendors may be able to manage some customization requirements through built-in configurable variables or similar settings, but again these customizations can be impacted by future development.  Vendors are typically focused on their core systems when designing and building enhanced features and functionality. Customizations in the field may result in significant challenges, delays and additional costs when they go to apply these enhancements to your custom system.

 

Tips for engaging your new technology partner

So, you’ve found a technology partner and want to get your project off on the right foot. Here are a few tips for a successful vendor engagement:

  • Adopt a phased approach – Define the objectives of each phase of the project, as well as the target audience, the scope, the timeline, the effort and the cost. Make sure you define success criteria for each phase and at the end of each phase meet with your vendor partner and review/reward them for success.
  • Use cases – Your technology vendor will be most effective in developing solutions for which there are well-defined use cases.
  • Always prototype – Ask your vendor to create a visual representation of the solution so that all parties can sit in a room and view it, discuss it and make changes, if necessary.
  • Set milestones – Well-defined milestones that everyone understands helps keep the project on track.  Keep them short, no longer than 45 days and make the vendor meet with you at each milestone date.
  • Product Showcases – Invite the vendor regularly to show you and your team what progress is being made – make them present it to you and make sure you attend these meetings because not attending is a sign that you lack commitment.  Ask questions in these meetings and get involved.
  • Steering Committees – Form a team with client and vendor reps and have the project managers (PMs) co-present the project status to the committee.  It is critical that the PMs work together and be committed to the success of the project.
  • Socials – You will solve more problems and uncover more ideas over a beer or a meal after a full day in the boardroom. Getting to know your vendor only contributes to their engagement.

Rick Hyde is CEO of Ticoon Technology. Follow him on Twitter or contact him at rick.hyde@ticoon.com.


Recent articles you may be interested in...