Enterprise-level FinTech for banks begins and ends with trust

Jun 27, 2022

Offering upside is great. Introducing risk? Not so much.

When B2C companies create products, they have the luxury of testing technologies gradually, adding and tweaking features over time, and deciding on priorities based on user feedback. That’s because they can usually depend on feedback from a broad pool of early adopters who have little or no risk as they test-drive an exciting new offering. Worst case scenario? the customer rolls his eyes, uninstalls, and goes on with his life.

It must be nice.

Because for those of us developing enterprise products for the banking sector, the rules of the game are altogether different; we require a mindset to match our customers’ scrupulous, methodical, overcautious attitude – an approach we understand and completely support. I’d like to tell you a little bit about how Kipp drives its product development based on values closely aligned with the banks we serve.

Our Story

First, a little bit about us. Kipp helps card issuer banks and merchants approve more purchases, leading to satisfied cardholders and increased revenue. We do this by supplementing the issuing bank’s risk assessments with the merchant’s supplementary data that can help determine whether a transaction should be approved or rejected.

Our founders come from the banking and credit card industries, and formed the company to select, customize and package a long list of robust, bank-level processes and technologies into a unique service to solve a particular problem. Our background taught us one keystone concept that drives our product development: banking is a traditional and conservative sector, and any improvement to existing tools must be bulletproof. A customer’s due diligence must reveal that it’s completely secure, with exceptional performance, scalability, resilience, and plans in place to handle edge cases. Put another way: they need to trust that we provide only an enhancement and upside, without introducing risk.

Every Component Counts

This mindset requires us to embrace and integrate a long set of acronyms: BCPs and DRPs (business continuity plans and disaster recovery plans for overcoming disruptive incidents), RPOs and RTOs (the time it takes to recover from a crisis, and how often data should be backed up), and many more. To maintain their hard-earned reputation for reliability, banks are passionate about these notions vis-a-vis their customers, and the tools we offer them must feature them as well.

Naturally, security and compliance are a top priority for banks; they will not contemplate facing a lawsuit or regulatory challenge because they agreed to add an Achilles heel in the form of an insecure, third-party solution. As such, we consider security a core part of each feature design spec; it’s not an add-on or a supplementary consideration. It is integral to any product design and development process, and we make this clear when presenting our solution in initial meetings.

And it’s not enough for us to be confident and to make claims to customers; we employ third-party companies specializing in penetration testing to make sure we haven’t missed a thing.

We also must include real-time monitoring and alerts to warn our team if our systems are – or will soon be – experiencing downtime or any problem that may impact performance, so we can deal with it even before the customer is aware. As a young company, we don’t have the luxury of dedicating a large team to this task, so this part of the system must be not only reliable but fully automated. No bank wants to hear that “the problem is being worked on and the system should return to normal soon.”

And, of course, aligning ourselves with a banking mindset is not only about the product itself, but about the integration process. We would never suggest that our product is plug-‘n-play; every financial institution has its own systems, processes, and priorities. Each client, therefore, has a dedicated integration manager, and each implementation has a certification process that we run in parallel to the customer’s own internal testing, to ensure that neither side has missed a step.

Don’t hide what’s under the hood

Before wrapping up, I want to make one thing clear — there is absolutely nothing wrong with revealing that you are leveraging third-party components in your product. Yes, you are a third party, and your under-the-hood components are even one step further from the customer. But enterprise customers who hear that you have chosen best-of-breed, well-known vendors may actually be more confident than if hearing that you are developing your own versions from scratch. In our case, for example, we use AWS with its collection of tools and services that provide flawless storage, management, bandwidth, etc. We use Mongo Atlas and Redis databases as a robust, cloud-based storage framework, allowing us to keep all data backed up in real-time. For each of these providers, we use all of their managed services to receive VIP-level support if we need help either for development or troubleshooting. Again, with partners like these, we control our total cost of ownership: we can scale quickly without the risk of finding ourselves re-inventing the wheel or requiring a rapid expansion of the teams to build and manage these systems.

To sum up – in many sectors, having an over-cautious, conservative client can be a challenge, lengthening the sales cycle, POC, and implementation. In our case, it’s the norm. (And as bank customers ourselves, we like it that way!) Even more so, our “secret sauce” is not a long list of patents and bleeding-edge IT – it’s our ability to create a product that begins and ends with an exceptionally long and thorough checklist of product features and assurances that a banking institution simply considers as a baseline.