By Melinda Jacobs, co-founder, Lucent Sky

I recently returned from Visa’s APAC Security Summit, where I was invited to sit on a panel titled “Balancing Risk and Innovation” — the only vendor to take the stage among a sea of bankers. Here is a selection of questions posed to me on the panel, and some abridged answers. Nothing below is representative of other panelists or institutional interests, simply some parting thoughts on Balancing Risk and Innovation as we return home from Phuket.

How do we ensure security is “built in” and not “bolt on”?

We actually spend a lot of time helping organizations transition from security (code security, secure development) as build-on to build-in — for most companies that’s an ongoing process, and the adoption of tools like Lucent Sky AVM that are used earlier in the lifecycle to promote secure development are part of that process. Secure products require secure processes, and more and more that involved security tools – process alone isn’t enough. Customers, prospects and partners we speak with are usually outgrowing their current processes because they have more security goals than they can manage with process alone. We recently learned that some people were using our software to reconcile outsourced code with internal code. This was not a problem that process alone could achieve because the amount of back and froth and reliance on other components is huge. Conversations about security needs and security tooling take place with many people, and that actually presents one of the greatest challenges to their adoption.

What can we in payments learn from other industries?

Developing safe and secure products starts and stops with the development process. Security has to be a team effort. I would challenge risk professionals to involve themselves in the development process as early as possible and become a partner in this process.

We always recommend knowing what’s being introduced by 3rd parties and to have tools in place to ensure that code is up to snuff; have systematic ways of assessing code quality and having tooling to rapidly pull things up to internal security standards. Other industries have done a better job of tooling for security and focusing on business metrics - how much time passes from introducing a vulnerability to removing it?

As we open the network to new participants, what do each of you think are the most important factors to consider?

SDLC visibility and hardening. Just because something functions doesn’t mean it’s good. A penny of prevention is worth a pound of cure. I would also recommend making sure there is a development and assurance process in place that incorporates security, risk and risk mitigation - ideally as early into that development process as possible

What role do compliance and security standards play?

What we hear from our clients is that compliance is a major security driver. This is good and bad. Security standards create common language, which is important and gives us clear insight into our client’s goals. However, those standards don’t always help companies understand how to meet those goals.

As a vendor, we are not a compliance provider. If the only goal of a security or risk practice is meeting an external standard (which often means on a periodic timeline) it’s harder for us to work with them and really make security a priority.

What do you see as gaps or opportunities for further collaboration in the global payment system?

Best practices that reach beyond compliance standards but into tooling or SDLC structures. We hear a lot about agile, but we’ve noticed in FinServ in particular these things have not caught on. That’s going to make the transition to secure product development harder, the further the timeline on those team structure transitions are.

Will tokenization solve everything?

No, there are no silver bullets!