Q&A with Tomer Kalimi, Head of PayKey R&D

How would you explain your role in the simplest way?

In essence, I lead two fronts: the first is running the engineering efforts of developing and perfecting the banking keyboard solution; the second is leading the integration work of our solution to each of our customers. This part is covering any aspect of the integration, from the moment that the contract is signed – all the way through launch day.


What does a typical integration process look like?

Once the bank sends out its keyboard design and functional requirements, we begin the process of developing the APIs (application programming interface). We manage each project by breaking it down into weekly sprints. On each sprint, we’re committed to deliver the customer certain elements of our product for review and testing. These weekly sprints are also an effective way to monitor the project heartbeat, staying close to the customer, getting feedback and change requests in near real-time, and making sure everybody’s on the same page.


How long do integration projects usually take? Are there any specific factors that impact the duration of the process? 

We typically complete the integration in 2 to 3 months. The exact deployment time depends mainly on the number of functional requirements that each bank defines at the beginning of the process – as well as the complexity of these functionalities. For instance, one of our customers wanted to customize the P2P service for three different scenarios: one for sending money to someone in the user’s contact list, one for passing funds for someone outside of the contact list, and another flow for paying a predefined beneficiary. From our end, we had to create flows that match each step in these scenarios. 


Your team is obviously working closely with the bank’s development team. What’s the division of labor between you and the bank? 

Our responsibility is to create an SDK that meets all the UX and UI requirements that each of our customers sets at the beginning of the project. Once we deploy this SDK, the bank’s part is to integrate it onto its app. I work closely with the bank’s development team and specifically with the product owner – the person assigned by the bank as the leader and focal point of the banking keyboard project.

Seems like a pretty demanding role. If you need to pinpoint one aspect that’s particularly challenging, what would that be?

I’d say it’s dealing with UI/UX requirements that are not clearly defined. Ambiguity is one of the biggest threats to any integration process. That’s why having good communication channels with the customer is absolutely key. Other challenges can stem from integrating our SDK with apps that were created in hybrid environments, as opposed to native iOS or Android. Without getting too deep into the technicalities, this can create some limitations around the app’s API and require us to come up with a workaround – but it’s definitely something we’re experienced in solving.


Part of PayKey’s offering is a simple integration cycle, with no involvement with the app’s back end. Walk us through what this means.

Everything we do is framed within the bank’s existing APIs. The SDK we’re delivering is essentially just another user interface to the bank’s app – an extension of the app, if you may. For banking and payment apps, this is an extremely important distinction. These apps run sophisticated payment rails that need to comply with the strictest regulations on customer privacy and data security. Any change in these back-end systems can compromise the integrity of the banking app and create a potential breach. We’re not touching any of that. The keyboard solution simply serves as a gateway to the existing app, without exposing any transaction or user data to third parties.


What happens after a bank launches PayKey’s solution – do you still have any interaction with it?

The team and I keep supporting the bank’s development team with any technical issue that may arise, but usually the intensity reaches a peak just before the launch – followed by a quiet period. The bank may of course decide to change some of the service flows that the keyboard supports, and this can create subsequent “mini-projects” following the main launch. One post-launch area that we do cover is proactive product updates: once a quarter we send out all of our customers a new version of our SDK, making sure they all have the latest keyboard features, be it NLP, new emojis or a new walk-through feature. 


Name one specific project that was particularly challenging. Anything that took your team to the limit?

A few months back we were working with Standard Chartered on launching a banking keyboard in Hong Kong. One of the requirements was that the keyboard would support handwriting text in traditional Chinese. That was unlike anything else we’ve tackled before, but eventually we had a good launch. When you think of it, the scope of projects that our team handles really is unique, working on hundreds of user flows in a dozen languages. This is part of the challenge – but also part of the magic.


What makes a good delivery manager?

In a nutshell: finding solutions, not problems. And then making sure everyone in our team is aligned with this mindset. Of course this also entails maintaining an open communication channel with the customers, our team members and essentially anyone who’s involved in the integration project.


Give me an example of something new you’ve learned in this role.

Just one…? Look, I think you simply can’t overstate the importance of effective communication, both with the customers but also internally – with our salespeople who manage the accounts and with our R&D team. More than anything, I’ve learned the importance of setting expectations early on in the project, making sure that anyone involved is aligned. Another thing I’ve learned is creating a culture in which issues and expectation gaps are raised early on.


What do you like most about your job?

Being in between PayKey and our customers. Leading the R&D team on one hand, and being very much customer-focuses on the other, means that we need to constantly keep pulse of the market, stay on top of any new technological offering in our domain, and be able to see our solution not only from our customers’ point of view – but also from that of their end-users.