devopsy.kinsta.cloud

Tag: fintech

  • TechStrong TV: How strongDM Helps Fintech MANTL With Access Management

    TechStrong TV: How strongDM Helps Fintech MANTL With Access Management

    The fintech space is growing by leaps and bounds, as more consumers shift their financial transactions online for both convenience and necessity during the COVID-19 pandemic. MANTL is a fintech startup providing banks and credit unions with the technology they need to meet the demands of their customers who want to do their banking from anywhere and on any device.

    In this TechStrong TV interview, we speak with Ben Conant and James Qualls of MANTL and Elizabeth Zalman of strongDM to understand how strongDM’s technology is helping MANTL with access management for its backend systems to enable a strong user experience.

    Check out the interview below and follow along with the transcript to find out more.

    Transcript

    Alan Shimel: Hey, everyone. Thanks for joining us for another episode of TechStrong TV. In this segment, we’ve got three people, as you can see, and let me introduce them to you. I’m gonna start with the lady, Elizabeth, Liz Zalman of strongDM. Hey, Liz—welcome back.

    Elizabeth Zalman: Thanks, Alan. Great to be here.

    Shimel: Okay, and then we’ve got two guys. The guy up in space there is Ben Conant—he’s not really up in space, he’s in Tenafly, New Jersey, but hey, you know, with the magic of Zoom, he could be anywhere. Hey, Ben, welcome to TechStrong TV.

    Ben Conant: Hey, Alan, thanks for having me.

    Shimel: My pleasure. And then last but not least, we have James Qualls. James, I didn’t even ask you pre-hand—where are you from? Where are you coming in from today?

    James Qualls: I’m in Harrison, New Jersey.

    Shimel: Okay, so, we’ve got a bunch of Northeast—Liz is up in New York and I probably have the biggest New York accent of all of you guys, so, there you go.

    But anyway, so, we have not—I don’t think we’ve ever covered MANTL on our show or even in any of our devopsy.kinsta.cloud, Security Boulevard, Container Journal, I don’t think we’ve covered MANTL before. So, let’s start off with a little bit about who MANTL is and then, as part of that, James and Ben, tell us what your roles are at MANTL.

    Conant: Sure. So, I’ll start. I’m Ben Conant, I’m the CTO and co-founder of MANTL, and MANTL is a fintech startup that provides banks and credit unions with the technology they need to meet the demands of modern customers. So, you can kinda think of us like Shopify, but instead of helping sort of medium-sized retailers have an online store without an engineering department, we do the same thing for American banks and credit unions.

    So, like, there’s actually 13,000 financial institutions in America, and 96% of those financial institutions are not Chase or Bank of America or SoFi that pump millions if not billions of dollars into technology. And these financial institutions really don’t have access to technology vendors that they like, want to work with, or provide them with what they need.

    So, that’s why MANTL exists. We are trying to reimagine what it can be to be a small bank, medium-sized bank in America or a credit union by providing technology that meets what they need.

    Shimel: Very cool. James, do you wanna—what’s your role at MANTL?

    Qualls: Yeah, so I’m the Director of Engineering here at MANTL and primarily responsible for infrastructure or liability engineering. I have the pleasure of architecting everything that MANTL runs on and we have the opportunity to run on a very modern cloud infrastructure. So, we use Kubernetes, everything’s configuration as code, running as Terraform. You know, we take advantage of as many cloud products as we can.

    Shimel: Excellent. And then Liz, we’ve had strongDM before, but for people who may not be familiar, give us the strongDM story.

    Zalman: The strongDM story is that the way people manage access to infrastructure has fundamentally changed since cloud. You’ve got an explosion of servers, database management systems, cloud providers. Kubernetes came into existence, and so doing it by hand or relying only on Active Directory, it doesn’t work anymore, and so strong creates a single control plane for you to both manage and audit the access of anybody who works for you—a contractor, an employee, service account to any infrastructure that is yours.

    Shimel: Cool. So, for purposes of setting up the discussion of how strongDM works with MANTL, Ben, I’m gonna ask to give us an example of some of this technology and apps that you guys are creating or helping maintain and power for your fintech clients, for your small and medium banks, credit unions, stuff like that.

    Conant: Yeah, so, the first product that we decided to develop for this market of sort of medium-sized banks and credit unions is a way for those banks to have a kind of open an account dot bank dot com website that was completely white-labeled and personalized to their brand, but really felt like signing up for Robinhood or Acorns or one of the sort of big fintechs that have a really slick sign up ________. Because a lot of these banks, you know, they don’t—in order to achieve the kinda deposit growth that they want to achieve, they have to go online, but they’re really suffering from not having a website that anyone would want to sign up for a bank account on, right? So, that was a very specific product, but there’s a huge market for it, so we decided to start with that.

    And then, you know, from a technical perspective, what does that mean? It means, for us, we have node microservices running in a Kubernetes cluster. We’re also talking to post press data stores in GCP, and then we need to control access and have firewalls and UAT environments for the banks to test stuff out using Cloudflare.

    So, you know, strongDM kind of ties into that, because as we grew and as we scaled, we needed to manage internal access to different pieces of our infrastructure, and we were actually thinking about building out our own little app to do this and have SQL access provisioning stored up in a database, but then, you know, through looking at vendors and finding strongDM, it seemed way better to sort of go with a company that was dedicated to providing that.

    Shimel: Very cool. Now, it would seem to me and, you know, I’m not the expert here, you guys are, but Liz, you know, when they’re setting up this sort of account opening app or online account opening app, that seems like something that strongDM would definitely be of much help to, no?

    Zalman: I think it was. I remember, James, I think, in our first conversation, you had very, I think the interesting thing about the MANTL team—whatever, it’s interesting about all my customers, but MANTL has a very clear point of view on the way that they want to do something in order to honor what their customers need. And so, James has always had a very clear point of view of, “We need something implemented like this, for these business reasons. I’ve tried on these other solutions. They don’t work for reasons X, Y, and Z, and so actually, MANTL is one of our most sort of forward-thinking, pushing the boundary customers that exist.

    I remember, James, when it came to setting up HTTP access for your internal employees and talking about header redaction and—I think it was Vault?

    Qualls: Vault.

    Zalman: The hosting of Vault, yeah. I was like, “Alright!”

    Shimel: Secrets.

    Zalman: “Gotta upgrade that.” [Laughter]

    Shimel: Yeah, no—Vault’s huge, right? I mean, you know, Vault is a little-known power—not little-known, but to those in the industry, it’s little-known, but outside of it? I mean, Vault may be HashiCorp’s biggest, you know, product, and they have some great products.

    But so, James, you know, Elizabeth’s kinda thrown you under the bus here, a little bit—it all comes to you. [Laughter] So, you know, how did the mission—you know, what else did you look at? What are the kinds of things, right, and how did you come on strongDM?

    Qualls: Yeah, so, I would say that we have, I would say the top three resources that we needed to gain access to—one, obviously, Vault, which, you know, it’s an HTTP based product, but you know, we could’ve gone with Cloudflare Access, ______ we could’ve gone with Google’s Identity-Aware Proxy. But the bottom line is that it’s much easier to manage and provision access if the system that you’re using is consolidated into one product, and I don’t want to have to manage access to these resources across three or four different products.

    So, we continued to look around and when we found strongDM, the first thing that we provisioned access for was databases. That’s something that no other product on the market does better than strongDM. strongDM covers a number of database protocols, we happen to be obsessed with Post Press. But strongDM supports things like Cassandra, things like BigQuery—so, you’re not necessarily limited in terms of protocol.

    There was an alpha that they were running where we got immediate access to the ability to not only proxy to databases through strongDM but also to proxy to HTTP based workloads. Vault happened to be the use case, and the e-mail that Liz is referring to is when I was talking about the audit logs and strongDM actually logging the Vault tokens in the early alpha and I requested that we have some kind of header redaction. And her team took our feedback immediately and within a very short period of time, they had implemented a fix or that. And to be honest, even in the alpha, the product was very usable. We were able to use it immediately and no one really knew that we were in an alpha, the product just worked. So, essentially, we were able to consolidate access to resources that we had actually been using private tunnel, a Pritunl, to run a VPN to those resources.

    After migrating to strongDM and after finally providing access to all of our resources, we use Post Press, Kubernetes, Vault, and there are some other internal resources that we provide access to all through strongDM, we were finally able to kill that VPN. So, we are an entirely identity-aware system at this point, purely because of strongDM. And then we have an added benefit when COVID hit, we were able to entirely go remote, because we didn’t have to scale a VPN. And this product is super high performance. We haven’t run into any bottlenecks, either, so you know, we’ve quickly grown over the last two years from 11 to almost 50 people now. And we’re all—all of us are presently remote, and all of us are using strongDM.

    Shimel: Very cool, very cool. And I don’t know the answer to this, and I hate asking questions I don’t know the answer to, but is there an application to use strongDM outside of MANTL’s own internal workforce for some of these banks, credit unions, you know, small to medium banks and credit unions as they—because, you know, there’s all kinds of financial regulations that you’ve gotta deal with here from q compliance standpoint and everything else. So, do you use strongDM beyond the internal MANTL team?

    Qualls: Liz and I have had a conversation about that, about potential applications for strongDM’s technology. I would say that probably MANTL’s biggest technical hurdle, when we’re integrating with a new bank is setting up network connectivity. And traditionally, that is, it’s by and large, it is usually an ________ VPN that we’re connecting to. And I see a potential application for strongDM there, although we haven’t attempted to see if it would work, or if one of our customers would actually be—or find that acceptable. [Laughter]

    Shimel: Ben, I’m curious what you think about that.

    Conant: Yeah, I think there is a huge market of banks that, you know, beyond just connecting to MANTL and allowing MANTL to operate with their sort of legacy systems, there is a huge market within banks where they have exactly the same problem, right? Like, people who are analysts at banks need to access lots of different data that’s all siloed in different data sources and different sort of network resources. We’ve heard a lot of our customers really struggling to set up or scale their own VPN solutions. And we’ve also worked with them to kind of, like, try and help mitigate those issues.

    But I think that strongDM is definitely a product that banks themselves should consider adopting, right? Because in the same way that it helps MANTL employees have highly compliant and secure and easy to manage access to the resources they need to do their jobs, banks have that problem but almost way larger than MANTL because they are 500 person organizations or 1,000 person organizations instead of a 50 person, you know, software company.

    Shimel: Yeah. I mean, because that was my thought on it, too, is these banks—I mean, the kinds of issues you’re talking about, James, that you guys are dealing with at MANTL and why you would use a strongDM kind of solution, you know, the small banks, community banks, credit unions—they got this, they have the same issues, right? Maybe some of them still are, you know, on legacy infrastructure, but if anything, I would imagine this whole COVID thing is accelerating their transformation there as well.

    Qualls: Absolutely. When COVID initially hit, you know, we had several banks, you know, just scrambling to scale their VPN infrastructure or bank—you know, some people were not actually even able to go beyond a certain point and they had to reconfigure their entire network topology as everyone was forced to go remote.

    In terms of, you know, in terms of how strongDM can be applied, I think that with COVID being a driving force behind that, I think that there’s definitely an opening for banks to start adopting newer technology, and strongDM is so easy to operate. It’s literally a don’t even think about it product. When we deploy it, we have the pleasure of deploying it on Kubernetes, so, we literally don’t even think about it. Scheduling and everything happen automatically. But strongDM is very well packaged. It’s a small binary, you give it a token, and you start it on any server you want. Yeah.

    Shimel: You know what, Liz, it sounds to me like James is giving you your new sales channel.

    Zalman: I actually just wrote that down. “Kubernetes—we literally don’t think about deploying it.” [Laughter]

    Qualls: Yeah. [Laughter]

    Zalman: No, customers have the best way—customers are the best from a product marketing perspective because they perceive the industry as they perceive it as a practitioner, and I’m—well, we’re practitioners, we’re also vendors. And so, their language is always the best. And they always know the right way to do things, I think.

    So, I can actually think of two product changes that James had requested. One was the header redaction in Vault, but the other thing was when strongDM deployed support for Terraform. The very first thing that James asked for was, “So, it’s great that you have a provider, but I need to be able to read in all of my configurations before I go and add strongDM to it, so when are you gonna support Terraform import?”

    And so, it’s very similar, right? You have practitioners, you have very forward thinkers for, like, “This is the right way to do things, and can you help me align to that?”

    Shimel: Excellent. Hey, Ben, I got a question for you. You know what? I love doing interviews with people like James and Elizabeth and we knock around things like, you know, Kubernetes and Terraform and Istio and maybe Cloudflare and stuff like that.

    But Ben, you know, you’re CTO and co-founder, you’re going to talk to these small community banks and credit unions, and even their IT departments, do they, you know, when you start bandying about stuff like this and this is—you know, does that resonate with them, or do they just say, “Hey, that’s why we have you here. You deal with that stuff. We’re not interested in what Kubernetes and strongDM is”?

    Conant: I think that there’s a very real sense in which the banks that are our customers are really purchasing as a service a large part of their company’s technology stack, right? So, if I’m the CTO or the CIO of the bank, you know, I’m trying to figure out, how do I move to the cloud in a way that is gonna make sense, right? And one big way to do that is to simply purchase MANTL. Because now your entire account opening stack is actually hosted on GCP, and you get all of the security benefits of that. And in the same way, you know, your—you want to be very involved with the decisions of, like, “Well, what technology is my vendor actually running?” Right?

    So, I think that the forward-thinking banks really do take it seriously and ask a lot of questions about our stack. I think maybe more importantly, you know, there is a very intense vendor due diligence process that even the smallest banks in America go through before allowing themselves to work with a technology vendor, right?

    And so, one thing that strongDM really helps us do is, you know, maintain a state of what we call perpetual compliance, right? So, we have an amazing Director of Security at MANTL, and we undergo SOC 2 audits, PCI audits, and other types of security audits every year. And, you know, having the capabilities that strongDM comes with out of the box allows us to, at a moment’s notice, produce the documentation that’s required for a SOC 2 audit for a lot of the stuff that we do. And that keeps our customers very happy. Because not only are they concerned with, “Oh, wow, you guys are on GCP, you’re using Kubernetes, you’re way ahead of the curve relative to the other vendors that we could go with,” but they also like the fact that we sort of breeze through these audits and are able to provide them with answers to the tough vendor due diligence questions that they do ask in the sales process.

    Shimel: Excellent stuff, man. Liz, I’m wondering if what Ben says he’s seeing kinda is parallel to what you guys see as well that, you know, especially dealing within the financial industry and fintech, there is sort of a high bar of due diligence in terms of is strongDM really secure, compliant, no back doors or—you know, I’m not creating a bigger problem by solving, trying to solve another problem.

    Zalman: Certainly. I think it’s twofold. So, companies get to a certain size where—and we’ve experienced this in fintech where they’ve rolled their own for some time, and then it gets to the threshold with respect to security RFIs they need to answer or they’ve hit a threshold in terms of employee base where they say, “Okay, I actually don’t wanna develop a core competency in identity and access management, and I want to offload that to a service provider.” Similar to how MANTL solves, essentially, a hosted web app and flow for credit unions to come into the 21st Century.

    And then, certainly, as part of any diligence process with us, we get asked, “What are your security—you know, what do you attest to? What are the results of your pen tests?” We did SOC 2 type 1 when we were eight people large, because it was such a core part of the sales process. I think customers want to be able to buy something that they have confidence in every aspect—that it provides the services, that it’s high availability and doesn’t go down and that it is as secure and people do what they say. So, certainly, that’s been a big part of the software since 2016.

    Shimel: Wow. That’s a while. Alright. Guys, we’re about out of time, but I realize MANTL, for people who want to get more information on a hot fintech startup out of Jersey there, where can they go on the web?

    Conant: Well, MANTL.com, M-A-N-T-L dot com, and you can actually see on James’ shirt it has the correct spelling of our name. But that—

    Shimel: Nice billboarding, James—good work.

    Conant: [Laughter] If we were both wearing that shirt, then it would’ve been a little bit weird, but I’m glad that it’s James and not both of us.

    Shimel: It wouldn’t go on the ISS anyway, so you know, you’re dressed appropriately, Ben—we’ll let it go.

    Conant: MANTL.com is a great place, there’s also been a number of industry publications about us, talking about how we’re helping in American Banker and others, helping community banks really become fintech companies, which we believe is their future, right? We think that all these fintech companies are trying to become banks. If you look at SoFi or you look at Simple Bank or any of these up and comers—really, you’ve got these small banks that, if they just had a platform to move and really innovate from a technology perspective, they are going to become the fintech, you know, [Cross talk] of the future.

    Shimel: It’s funny, they just, from both sides of the spectrum, converging on a common market is what you’ve got there. But Elizabeth, strongDM, for people who may not know, where do we go to get more information?

    Zalman: strongDM—S-T-R-O-N-G-D-M. Here at strongDM, the DM stands for Dragon Matrix. [Laughter]

    Shimel: Okay.

    Conant: I did not know that. That’s awesome.

    Zalman: Yeah, it came up at our last on-site—although, I gotta say, everybody wants T-shirts, and I’m like, “No, no, no. No T-shirts, I want a trucker hat.” But then that would look weird on camera—James’ shirt is much more effective on camera, so.

    Conant: [Laughter]

    Shimel: Yeah, no—the shirt works, James. Good work. Hey, guys, we’re gonna call it a wrap on this segment here for TechStrong TV. James Qualls, Ben Conant—did I mispronounce it? yeah okay—from MANTL, and of course, Liz Zalman, from strongDM. Thanks for joining us. This is Alan Shimel—we’ll be right back with our next guest.

  • Harnessing the Power of Developers

    Harnessing the Power of Developers

    In our fast-moving digital economy, organizations across just about every industry are faced with a stark reality: to remain competitive and deliver the best possible customer experience, they must evolve continuously. The fintech industry is a great example of this–the sector’s growth and focus on excellent customer experience has been driven by external developers rather than incumbent players.

    For many companies, particularly in the service industry, improving customer experience now means developing new apps and services that will maximize the customer journey, engender deeper trust and secure customer relationships for the future.

    The aim is to continuously produce innovations that create delightful customer experiences, which in turn will drive ROI. In its 2019 Technology Industry Outlook, Deloitte highlighted the fact that the “democratization of innovation” is set to be a key strategic factor in the coming years. As cloud infrastructure makes it easier to innovate at speed, “medium and small enterprises can harness powerful capabilities once limited to a select few.”

    That might be a new SaaS application, for example, or the implementation of emerging tech such as AI or VR–anything that helps the company provide a more efficient or accurate customer service. A simple example could be integrating complementary, adjacent solutions to add additional value to end customers.

    Companies need to innovate in order to create unexpected functions and capabilities that will delight. But how do companies go about making that a reality? In a nutshell, there are two groups that can help you innovate: your own developers and the wider developer community. Having the right people involved and the right programs in place for both of these channels will allow you to scale and deepen your innovation more effectively–and ultimately create experiences that your customers cannot live without.

    The more you engage with developers inside and outside your organization, the faster you can accelerate your time-to-market for new innovations and, crucially, ensure that those innovations meet real customer needs.

    In-House Developers

    Building an effective in-house development team to meet customer needs is about more than just hiring the right computer skills. Companies need to aim for a fearless, fail-fast culture that lets teams go above and beyond in answering customer needs. This need not apply to all developers–there will be some focused on refining the core product set, for whom fail-fast may not be the ideal working model. However, in the pursuit of unexpected offerings that will delight customers, a healthy attitude to both fail-fast and conventional development is essential.

    Often, organizations are held back from being the best they can be by ingrained, deep-rooted cultures. The power of “the way we do things ‘round here” can be hard to crack, but good leaders must help staff buy into change as an ongoing process that will help them and the business to succeed in the long run.

    That’s where the concept of experimentation and fail fast comes into play. In these environments, developer teams are given permission to try things out without having to go through multiple rounds of approvals and senior buy-in. That means they can go from an initial idea to a fully testable concept in, say, weeks rather than months or years. It also means they can run their blue-sky ideas through a crash course of reality, bumping up against unforeseen problems–what some people might consider failures, but I think of more as learnings–without being penalized for it.

    When developers are given this permission to get ideas off the ground quickly, the benefits to the organization are obvious. Improved access to innovation; a greater chance of discovering more effective ways of working; and a supportive, forward-looking culture that helps to enthuse non-technical staff as much as developers themselves. The same is true for customers–they will benefit from innovations that improve their experience, surprising and delighting them with the idea they didn’t know they needed, but which exactly addresses their needs.

    Practical Considerations

    There are other key issues to address, particularly senior buy-in and customer-centricity. First, it’s essential that developers know their work is valued by senior leadership. Senior leaders need to trust their experts and not just allow but also champion the fail-fast model if the company is to benefit from the successful innovations that come out of it.

    Second, developers need to work in close communication with customer-facing teams to ensure their efforts are directed toward innovations that will translate into improved customer experiences. In other words, it’s important developer teams innovate with the company’s core goals in mind–not just for the sake of it, however tempting that might be.

    There are also pragmatic issues to be addressed, such as ensuring your APIs or SDKs are well developed, and there are good documentation/guides to help use these APIs. This is required for both in-house and external developers.

    External Developer Networks

    Having a wide network of development partners can also help rapidly scale innovation and deliver solutions that exceed customer expectations with speed. By building a community of great minds around the mutual benefit of market-ready innovation, organizations can unlock far more valuable projects, with positive effects for them, their customers and their partners.

    An effective developer partnership works on the basis that there is a symbiotic relationship where each side has something to offer to the other. For example, the developer partner may come from a smaller company who has specific expertise and can benefit from the financial support and expertise of the larger organizations. While both sized organizations can benefit from the diverse thinking, agility and challenger mindset of the developer partnership. Whether you’re a large company looking to fast-track customer-centric innovation or a small company with a great customer-centric idea that needs a boost onto the next rung, a healthy developer network can be highly beneficial.

    As an example, the accounting industry is currently undergoing a major cultural change, with accountants increasingly seeking to provide customers with value-add strategic services to maintain their competitive advantage. Technology is driving a consultancy-first service model. Accountants have access to more data than ever before, and as a result they can help clients to make effective business decisions based on new analytical insights.

    However, making the jump to effective consultancy requires new tools and innovations to turn raw information into usable insights. By working in partnership with a network of cutting-edge developers, accounting software providers can help to conceive, road-test and launch user-friendly solutions.

    The value of developer networks is also evident as you look at domain specific needs that might span a particular industry or a particular region. One company may not have the expertise or bandwidth to do it all–but by building effective communities of developers, an organization can expand their reach to tap into niche areas of expertise. It also gives the company the ability to deliver innovations more rapidly. Every company has a limited set of resources, and additional developer networks can help scale this innovation. For the developers, the value lies in reaching markets and customers they may not previously had access to.

    Taking Innovation Out of the Lab and into the Market

    Whether your company uses in-house developers or a partner network (or both) the core goal should be to hone ideas into realities through collaborative working practices. When developers and customer-facing teams understand one another, they can achieve great things.

    It’s an exciting time in the industry. Technology is evolving faster every day, solving more problems and opening up new possibilities. For businesses of all varieties, harnessing the power of developers should be a core priority. It’s not a question of pursuing innovation for the sake of it–it’s about taking practical steps to ensure you maximize the positive impact of tech on your customer experience.

    — Shivani Govil

  • Fintech: A Profitable and Growing Developer Career Path

    Fintech: A Profitable and Growing Developer Career Path

    What do you think when you hear the word “fintech”? It’s been around for almost five decades, yet it has only just been officially recognized as part of the English language. In the Merriam Webster dictionary, the word is defined as: “Products and companies that employ newly developed digital and online technologies in the banking and financial services industries.”

    A number of factors in recent years have paved the way for the boost in profile for fintech, bringing about phenomenal growth in the sector. In some parts of the world, governments and regulatory bodies have fueled this growth by issuing regulations that open up the banking sector to increased competition, creating a great many opportunities for finance and technology professionals alike. And from the other side, not only are banks being at most compelled, and at least pressured, into opening up to competition, many are now actively seeking to collaborate with more agile third parties—namely fintechs and developers —to innovate the services demanded by their customers.

    So, what exactly are the opportunities available for developers in this newly defined sector?

    From the Classroom to the Boardroom and Beyond

    I am confident that there has never been a better time than the present for developers to get involved in the financial services industry. It’s a bold statement, but one that bears out when the remarkable amount of support being directed at fintech is considered.

    Today, the industry is receiving unprecedented political backing as multiple jurisdictions vie for fintech hub status. From the United States to Hong Kong, from Germany to the UK, governments are offering financial support via tax incentives and grants in a bid to woo fintechs and developers to their financial centers. And it’s no wonder, given how lucrative a business sector it has proved to be. In the first half of 2018, VC-backed fintech companies reportedly raised more than $25 billion in funds. CB Insights’ data shows there are currently some 29 fintech unicorns (venture capital-backed, private businesses worth more than $1 billion) worldwide, with an aggregate value of $84.4 billion—and this is expected to keep on rising.

    Even educational support is being offered to future-proof against skills shortages, with academia and financial firms collaborating to create fintech-related graduate training schemes and degree courses.

    Open Banking

    Around the world, particularly in Europe and parts of Asia, governments and industry bodies are lighting the way for a new approach to collaboration with fintechs and developers. In Europe, the second payments Services Directive (PSD2) and the UK’s Open Banking initiative are opening up the financial services market to third parties eager to enter the space. These initiatives, and others like them, compel banks to share their precious data with third parties at the request of their customers—meaning they can no longer take their hitherto market hegemony for granted.

    Here in the United States, the Consumer Financial Protection Bureau (CFPB), the body that regulates the offering and provision of consumer financial products and services, has released a set of data sharing principles that provide an advisory framework for financial institutions. Though the CFPB’s guidelines are non-binding, they do show that there is growing pressure from regulators for the financial sector to be more transparent with customer data.

    Collaboration is Key

    When it comes to collaboration between fintechs and banks, one might expect there to be a certain amount of resistance from both sides. Fintechs are traditionally disruptors, while financial institutions don’t take kindly to being disrupted. A pPlatform-as-a-service (PaaS) approach can help enable collaboration that is beneficial for both sides.

    The ability to collaborate through a common platform, hosted in the cloud, offers the potential for fintechs to significantly reduce application development time, often from months to weeks. Users can bring innovation to market at pace using a low-code, cloud environment and sell applications to the banks without needing to build a global sales team or worry about a scalable infrastructure. Pre-integrated developer tools, a sandbox environment and an API catalogue also speeds application creation and levels the innovation landscape. With platforms, the fintechs with the deepest pockets no longer dominate the market simply because they have the resources to snap up opportunities. In the platform sandbox, smaller firms, startups and independent developers can bring their own offerings to the table.

    As the model for bank innovation changes, a platform approach also makes it easier for financial institutions to transform their businesses, extend product capabilities and access innovation. Banks can leverage their own development capabilities to create and deploy applications on top of their core systems and can collaborate with fintechs to build and access new capabilities they need quickly through open APIs.

    A key part of the PaaS approach also gives developers the ability to make apps available to banks globally through a digital shop front, much like Apple’s iOS App Store. So, not only are developers and fintechs able to distribute and monetize their apps, banks can readily test and deploy them.

    Get Onboard

    Financial institutions are starting to recognize that an open platform approach is the fastest way to onboard fintechs to enhance their current business offerings. As this understanding deepens, so too will the demand for skilled professionals and new applications. Banks in the not-too-distant future will not only concern themselves with the services they want to deliver, much consideration will be given to the fintechs most able to provide them in a timely manner.

    It’s not just in retail banking that the opportunities lie, but across all areas of financial services—from investment management to corporate banking, payments, trade finance and capital markets. The coalescence of these two considerations is leading to a change in the industry zeitgeist, meaning the scope for innovation across all areas has widened significantly. The great earning potential for those with the ability to convert good ideas into innovative apps and services has never been more apparent.

    So, developers, as banks wait with open arms (and APIs), now is the time to enter the burgeoning world of fintech.

    — Mitesh Soni

  • Enabling the Financial Services Shift to Microservices

    Enabling the Financial Services Shift to Microservices

    The financial services industry historically has been riddled with barriers to entry. Challengers found it difficult to break through low margins and tightening regulations. However, large enterprises that once dominated the market are now facing disruption from smaller, leaner fintech companies that are eating away at the value chain. These disruptors are marked by technological agility, specialization and customer-centric UX.

    To remain competitive, financial services firms are reconsidering their cumbersome technical architectures and transforming them into something more adaptable. A recent survey of financial institutions found that about 85 percent consider their core technology to be too rigid and slow. Consequently, about 80 percent are expected to replace their core banking systems within the next five years.

    Emerging regulations meant to address the new digital payment economy, such as PSD2 regulations in Europe, will require banks to adopt a new way to operate and deliver. Changes such as PSD2 are aimed at bringing banking into the open API economy, driving interoperability and integration through open standards. To become a first-class player in this new world of APIs, integration and open data, financial services firms will need the advantages provided by microservices.

    Microservices’ 3 Key Advantages for Financial Services

    Enhanced Security

    Modern fintech requirements create challenges to the established security infrastructure. Features such as digital wallet, robo-advising and blockchain mandate the need for a new security mechanisms. Microservices follow a best practice of creating a separate identity service to address these new requirements.

    Faster Delivery

    Rapidly bringing new features to market is a cornerstone of successful fintech companies. Microservices make it easier for different application teams to deliver new functionality independently to meet emerging customer demands. Microservices also scale well to accommodate greater numbers of users and transactions.

    Seamless Integration

    The integration layer in a modern fintech solution needs a powerful set of APIs to communicate with other services, both internally and externally. This API layer is notoriously challenging to manage in a large monolithic application. Microservices make the API layer much easier to manage and secure through isolation, scalability and resilience.

    Service Mesh: Simplyfing Management of Complex Microservice Architectures

    In the face of rapidly changing customer, business and regulatory requirements, microservices help financial services companies quickly respond to these changes. But this doesn’t come for free; companies take on increased operational overhead during the shift to microservices. Technologies such as a service mesh can help manage that.

    Service mesh provides a bundle of features around observability, security and control that are crucial to managing microservices at scale. Previously, existing solutions such as DNS and configuration management provided some capabilities such as service discovery, but didn’t provide fast retries, load balancing, tracing and health monitoring. The old approach to managing microservices requires that cobbling together several different solutions each time a problem arises, but a service mesh bundles it all together in a reusable package. While it’s possible to accomplish some of what a service mesh manages with individual tools and processes, it’s manual and time-consuming.

    Competition from innovative fintech startups, along with ever-increasing customer expectations means established financial services players must change the way they deliver offerings and do business with their customers. Delivering on these new requirements is difficult with legacy systems. Financial services firms need a software architecture that’s fit for purpose—agile, adaptable, highly scalable, reliable and robust. Microservices make this possible, and a service mesh makes microservices manageable at scale.

    — Zach Jory

  • The Move to Platform: Unleashing a Wealth of Opportunities in Fintech

    The Move to Platform: Unleashing a Wealth of Opportunities in Fintech

    Closed, legacy systems and requirements around availability and security remain major obstacles to innovation in the financial services industry. But there’s now an appetite for change and a growing recognition of the benefits to be gained from a platform-based approach. This article explores the legacy challenges that still plague financial services, examines the case for a move to platform and looks at the opportunities for developers in fintech moving forward.

    Overcoming Legacy

    Would you be surprised to learn that most financial organizations are still using the same legacy core banking systems they were using in the 1980s? Developed using languages such as COBOL, these proprietary back-end systems were deployed to speed the efficiency of specific tasks, including bank transactions and financial trading.

    As organizations added more applications over subsequent decades, they retained their core banking systems as the foundation on which everything else was built. This approach maximized ROI and achieved the best possible performance because mainframes were still faster than x86 servers.

    Each application was selected for its “best of breed” capabilities that solved specific business challenges, increased operational efficiency and protected against downtime. However, the new applications introduced new file formats, new programming languages such as C++ and new operating systems including Unix, Windows and flavors of Linux.  Banks now had even more silos and the need for even more technology experts to maintain them.

    Fast forward to a few years ago, and the next wave of innovation was driving digital workflows. Banks invested significant time and money to create custom connections between all their silos. Building on legacy was still faster and less risky than ripping and replacing the back end. However, point-to-point connections and new web-based apps introduced even more technologies such as Python, Ruby, Java and Javascript. Banks’ IT departments were now almost completely absorbed with just maintaining their legacy environments and meeting the needs of employees.

    Large banks today can have thousands of applications, and some of them can have 10 million lines of code. Even a small change can cause stability issues and downtime. A bank can lose millions or even billions of dollars a day if just one application goes down. This makes testing extremely critical. But the complexity of legacy environments translates into slower development cycles. Not only do projects require experts that understand legacy technologies, but also it often takes significant time to stand up the complicated systems to match the complex production environments. If a new application makes it to production, it’s often too late to make a competitive difference.

    What’s the Way Forward?

    Consumers today expect modern apps and services and they’re not seeing them fast enough from their banks, lenders and investors. Financial organizations must find a way to meet their customers’ expectations for anytime, anywhere access to their data and services, while maintaining their legacy investments.

    One way to accelerate development of modern customer-centric services with legacy systems is to use a cloud-based platform, based on open technologies, to facilitate communication between legacy systems and all new apps and services. This platform-based approach makes it possible to innovate and meet other requirements including security while retaining legacy as long as needed.

    We’re starting to see a platform revolution in financial services. By the end of 2019, financial experts predict that 25 percent of retail banks will be working with startups to replace legacy and mobile systems.

    An open-standards based platform that connects developers with global financial services companies is crucial in allowing collaboration and innovation on a global scale. So, instead of always having to develop dedicated solutions for individual silos, developers can first check and see if someone else has developed an app with an open API that solves all or part of their challenge.

    What Are the Opportunities for Developers?

    It’s an ideal time for developers to get involved in bringing new ideas and innovation to financial services. Banks are finally facing up to the threat posed by the tech giants and the need to digitally transform the services they offer.

    Banks’ willingness to open up and adopt a platform-based approach is growing and they are also starting to recognize the value in being able to tap into all the IT creativity and innovation that’s happening in other industries. Importantly, developers will no longer require specialized knowledge about the proprietary APIs and technologies supporting their legacy systems.

    Studies show that some of the best solution ideas come from people from analogous fields—fields that are different from each other but the same on some structural level. So, a developer who works on genomic data models may be able to help a hedge fund manager who needs to uncover patterns in data. Or a retail developer might offer new perspectives on how to manage transaction processing.

    In the past, if a bank wanted to evolve their technology in some way, they needed to engage a fintech, and there was a lot of back and forth. The process was so complicated. It could take months and many times it wasn’t successful. Using a platform-based approach that provides connectivity to a standard set of pre-built and fully integrated open APIs can dramatically optimize the software development environment, allowing apps to be developed in a matter of days.

    Giving developers the ability to interact with open APIs in a sandbox environment will allow them to experiment online in bringing data into their applications and to test the inputs and outputs in a safe environment. Using a low code development environment, they can create UX and business logic in a few clicks and test them in real time. Publishing those apps in a store helps developers to get visibility and solve the distribution problem. Finally, banks can purchase them and run them in the cloud through automated delivery, supported behind the scenes by CI/CD pipelines. Banks don’t need to worry about provisioning any additional hardware as the apps run in the cloud, and support hybrid scenarios as well, where the core system remains on-premises.

    The platform ecosystem is the future of how apps will be developed, deployed and consumed. It enables such convenience for the user that it is inevitable. Being able to reuse tools that other people develop instead of reinventing the wheel in every project will also save a tremendous amount of time.

    My advice for developers today? Seriously consider what value you can bring to financial services—banks and other providers need your support!

    — Félix Grévy

  • Why Open Banking Should Consider DevOps

    Why Open Banking Should Consider DevOps

    There is a craze sweeping Europe, and rippling across the world—and no, I’m not talking about the next British Invasion. Open banking is a trend that’s significantly altering how banks work with fintechs and maintain agility in the global marketplace.

    A main enforcer is PSD2, a piece of EU legislation that sanctions access to personal banking data. It’s resulted in an explosion of EU banks providing public application programming interfaces (APIs) for fintechs to develop with. The implications aren’t limited to Europe; many banks all over the world are looking to PSD2 as a baseline, forcing some tough evaluation of how financial architecture should adapt.

    Banks are also under consumer threat to evolve or get out — a 2016 Accenture study found that 78 percent of respondents would bank with a tech firm such as Amazon or Google.

    As banks transition into savvy software providers due to market pressure, one thing is certain: they must adopt agile software development strategies that streamline the deployment and maintenance of these services. In other words, banks must adopt a DevOps philosophy to maintain a market advantage.

    Open Banking Evolves Bank Architecture

    The bank has become programmable. Many banks are now required to allow third-party authentication and access to payment, account information, fee details and other data. This involves support for various integration methods; SDKs, APIs and OAuth for authentication, as well as documentation, sandboxes and other developer tools. Whether they like it or not, banks are now SaaS providers.

    It should be noted too that open banking is not limited to the European Union. The UK’s open banking standard is the Competition and Markets Authority (CMA), and Australia, Japan and other countries are making similar inroads with regulating banking data. The excitement has also encouraged North and South American players to open up.

    The new bank APIs help bypass traditional methods, saving a ton of time. In an article in American Banker, BBVA noted that online e-commerce system Dwolla was able to slash the typical three-day to six-day deposit time frame using their payment APIs. “We’re allowing that all to occur in real-time,” said Chad Ballard, director of mobility and new digital business technologies at BBVA Compass.

    Letting FinTechs focus on web UI development helps banks focus on their core competencies: banking and authentication. Establishing connections via API-driven microservices is also a safer alternative to screen-scraping.

    Why DevOps for Banking?

    Banking Exchange defines agile banking as “the future of retaining relevancy for banking as a whole.” For open banking to be successful, the platform must be tested, monitored and secured for fintech consumers. Sounds a lot like the hallmarks of quality DevOps practice.

    Popular services Google Maps, Uber, Stripe, Twilio and others have adopted an API-as-a-product mentality. These programs adhere to best practices, iterative feedback and agile development methodologies to excel. Similarly, for banks to remain competitive, they must treat their platform architecture and public gateways with the same tenacity.

    For banks, uniting iterative development with stability testing—essentially the Dev + Ops mantra—for their APIs, microservices and frameworks will go a long way to help reach open banking goals and maintain future regulations on API performance standards.

    A DevOps mindset is crucial to consider early on in the open banking journey, as it can impact how banks address:

    • Iterative development and testing: By tying in iterative development with stability testing, organizations can surpass the time limitation often incurred between shipping versions between development teams and testing teams.
    • Continuous monitoring: Many tools are available to monitor the CI/CD pipeline, helping banks respond to issues and improve uptime.
    • Versioning strategies: DevOps in banking will see the larger picture, working in the REST mantra to build on the scale of decades to avoid breaking change.
    • Transition to microservices: As enterprises dispose old monolithic architectures, bitesize services are arguably more appropriate for modern banking; however, they come with unique caveats that DevOps can address.
    • Collaboration between silos: By pivoting to more point-to-point, collaborative processes, banks can reduce friction to meet the responsive expectations set by FinTech, who are becoming new public faces for banking.

    An end result of DevOps is to increase agility in an organization. Especially for large banks, this signifies drying up the traditional “waterfall” development life cycle known to stigmatize the corporate approval process.

    Case Studies: How Banks Are Utilizing A DevOps Cycle

    Many banks have been vocal about what they are doing to ignite positive technological innovation alongside third parties. For example, Capitol One’s DevExchange recently announced a new initiative called experimental APIs. “They are designed with the goal of getting early feedback from the community around API desirability and design before the product release,” the company noted in a blog post.

    In this experimental setup, operational cues inform development. Getting the two sides to talk and respond to community feedback is paramount for DevOps to succeed.

    For banks to adopt an agile makeup, Manfred Bortenschlager, Red Hat’s director of Business Development for API-based Integration Solutions and API Management, recommends what he calls an “agile integration.” This involves a distributed integration for greater flexibility, containerization for the ability to scale better and managed portals for reusability.

    Another interesting effort is that of CIBC, a Canadian bank that is responding to the open banking movement with a responsive microservices framework the company has developed using open source components.

    What’s evident is that many banks already acknowledge DevOps principles as key for innovation in their sector. Through the the use of iterative testing, innovative tooling and automated workflows, banks can achieve greater operational efficiency.

    Open Banking Must Follow Software Development Practices

    A result of the open banking movement is that banks must keep technological pace with fintech. Especially with regulatory pressure, banks must consider how best to approach new technological initiatives.

    DevOps is a way to mitigate concerns. As a philosophy for uniting technical procedures with responsive operations, it’s a prime strategy for banks to consider when readdressing their technology.

    In defining what “agile” embodies for banks, Steve Williams of Cornerstone Advisors said: “The idea is you need to start taking the management and operations of a financial organization and start adapting some of the things that have made technology companies viable.”

    American Banker echoes this, believing that “banks should be more like software companies.”

    Now prodded by open banking, it’s high noon for luddite banks to embrace contemporary software development practices; that means incorporating DevOps into the open banking agenda.

    — Bill Doerrfeld

  • Why Financial Companies Love Continuous Delivery

    Why Financial Companies Love Continuous Delivery

    The other day I was on the American Express website paying bills and browsing around the benefits and services afforded me when I ran across a “who we are” section. It read:

    “We’re a global services company that provides customers with access to products, insights and experiences that enrich lives and build business success.”

    Surprisingly, the term “financial” was missing from the description. This led me to wonder if other financial institutions are evolving how they think about themselves. Here are some other examples:

    • Bank of America: “Here to help connect you to what matters most.”
    • ING: “Empowering people to stay a step ahead in life and in business.”
    • MasterCard: “As a technology company, we connect individuals, businesses and organizations around the world, creating greater opportunities for all.”

    Financial Companies Love Their Customers

    My unscientific assessment of various financial services companies suggests that they are centered on delighting their customers. They are transforming who they are by altering their customer engagement models and essentially becoming better software companies. MasterCard has even reclassified itself as a “technology” company. These companies are transcending the role of transaction engine to offer seamless, intuitive digital experiences for their customers.

    And the proof is in the performance. According to Forrester’s Customer Experience (CX) Index, financial services firms, including retail banks, credit card companies, investment firms and auto and home insurers, are some of the top brands worldwide when it comes to CX.

    You might think that large financial institutions would be digital laggards because of legacy infrastructure, regulatory compliance pressures and overall risk-avoidance. But you’d be wrong.

    In another study, 81 percent of financial services firms said they are embracing digital to redefine their businesses, and 87 percent are on the DevOps bandwagon. Sixty-one percent even said they are disrupting their industry with advanced digital initiatives.

    To stay competitive and improve their customer experience aptitude, financial services firms are undergoing significant digital transformation.

    Getting the Pulse of Fintech Continuous Delivery Adoption

    But how progressive are these firms in terms of their application delivery practices? Working with CA, Gatepoint Research recently surveyed more than 100 IT executives from financial services companies to take the pulse of where they are in continuous delivery adoption. Results can be found in this report and infographic.

    First off, to see if these companies might be considered unicorns or stragglers, they were asked the total volume of monthly deployments in all environments. Forty percent fell at the low end with fewer than 50 deployments per month. Now, lower deployment numbers could mean that these are less agile organizations or that they have fewer applications in general. Somewhat correlative to lower deployment numbers, the survey found that 48 percent currently are not using an application release automation (ARA) solution. Without automation, it’s tough to scale release processes—particularly to keep up with agile development.

    Moving up the spectrum, 41 percent are moderately prolific at 50-500 deployments per month, and then 15 percent are what I would consider rock stars with more than 500 (7 percent of those over 1,000). Those doing hundreds of deployments a month often have agile development teams and more modular applications. They likely have continuous delivery practices in place that push more frequent, iterative deployments left, helping higher-quality applications to move through the pipeline to production.

    The primary application delivery goals for financial services firms for the next 12 months are to get better control of release processes, tools and environments; to reduce risk and failures; and to release applications more frequently. All of these needs typically stem from companies undergoing digital transformation—it feels more chaotic and disconnected, manual processes are breaking under the weight and there’s intense pressure to move faster.

    Compliance was not a top goal, and the majority (83 percent) claim that their current release process is adequate to meet regulatory requirements. However, they did acknowledge that they could improve in terms of knowledge safekeeping and auditability of the release process.

    The data certainly shows that financial services companies are adopting continuous delivery practices in some form and exploring solutions, including many open-source tools, to help them get the job done. They currently are focusing continuous delivery practices on tracking and reporting releases, planning and scheduling releases and automating test deployments. These practices ultimately help financial services companies to release high-quality applications anywhere at any time.

    How Continuous Delivery Helps Fintech Win

    Continuous delivery sits at the heart of many digital initiatives because of what it enables these companies to achieve for their customers:

    • Delivering features and updates that customers need when they need them
    • Delivering applications that meet performance and quality expectations of customers
    • Delivering secure, compliant applications (for external and internal customers)

    Continuous delivery enables continuous devotion to the customer experience.

    Continuous Release: Fast Customer Response

    With continuous delivery, you establish an application release workflow that automatically connects a developer’s update to parallel testing to staging and ultimately to production release. Because of the underlying end-to-end automation technology, these steps can happen quickly, seamlessly and with little to no manual intervention. Some might call it “push button release” or “zero-touch release.”

    It’s a controlled, tracked, governed, collaborative process. Application stakeholders stay aligned as application changes traverse the pipeline. Your customers can have access to fixes, updates and new innovations in days instead of weeks or months.

    Continuous Testing: Building in Quality

    In contrast to the significant time penalties and shortfalls that can happen with manual testing, in the continuous delivery pipeline, testing is shifting left and happening in parallel. Hand-offs and feedback loops are automated and efficient.

    Testing can happen earlier and without delay with the help of test environment simulation. Testing is on target through automatic test case creation, even from requirements. Testing is real-world with on-demand test data generation. And testing is rigorous with developers able to performance test apps at their end. The continuous testing that occurs as part of the process helps to build in quality and ensure top performance before reaching the customer.

    Continuous Compliance: Audit-Ready Processes

    Ensuring applications are compliant and secure is critical for your customers. It’s making sure customer information is safe and that application changes are tracked sufficiently for SOX or other reporting. It’s also about helping out those internal “customers” like auditors to prove compliancy and easily build reports.

    An automated continuous delivery pipeline can track releases, apply role-based governance, orchestrate proper data masking, deploy security policy updates and provide an audit trail for application releases—who did what, when and why. All this data can be collected and reported easily, which saves time and effort for auditors. You essentially stay compliant and secure all the time.

    Customer Satisfaction Through Automation

    Financial services companies are laser focused on using technology to delight and retain customers. And continuous delivery is the application delivery practice that’s underpinning these efforts. The companies that are exceptional at this, with thousands of deployments per month, are using automation tools such as Application Release Automation (ARA). These tools are the backbone of continuous delivery, providing the automated orchestration, governance, tracking and reporting for your pipeline—development through production.

    That’s why I’m not surprised that leading financial services companies make up a large portion of CA’s release automation customers, including Euroclear, GM Financial, ING, Jewelers Mutual and Western Union. Our customers put high value on delivering excellent customer experiences and are implementing modern software delivery methodologies, practices and associated tools to support their efforts. GM Financial recently said it is “the software company that does auto finance.”

    If you are serious about customer satisfaction and staying ahead of nimble competitive threats in the market, you must get serious about end-to-end automation. It’s time to truly embrace the practice of continuous delivery to be able to consistently release applications that are progressive, always compliant and completely customer-satisfying.

    — Patricia Johnson