Tag: financial services

  • Q&A: Database Security in Financial Services with Yaniv Yehuda

    Q&A: Database Security in Financial Services with Yaniv Yehuda

    As financial institutions are adopting DevOps best practices to speed up application delivery the database remains the stumbling block causing delays, introducing risks, slowing down release cycles and wasting valuable internal resources. At the same time, compliance and audits are managed manually, complicating the process even further.

    It is time to bridge the gap between the database and the CI/CD process in order to achieve faster release cycles and simplify compliance, security and auditing.

    Yaniv Yehuda, co-founder and CTO at DBmaestro, answered a few questions regarding security challenges in the financial industry and DevOps.

    Yaniv is one of the distinguished speakers presenting at this year’s FinConDX Virtual Summit. During his session “Database Devops For Financial Industry: Security And Audit,” Yaniv will take a deep dive into DevOps best practices and the issues related to the database.

    What are some of the main challenges financial industries are facing when it comes to security and the database?

    In the modern world you need to move faster, you need to automate, but at the same time you need to bring security to the front. You can’t deal with security and compliance after the fact, it is just going to slow everything down. As everyone is trying to accelerate, compliance and security must be baked into the process. What the financial industry is looking for is a way to make sure security and compliance are dealt with automatically, while at the same time aiming for the productivity and process improvements when dealing with data. What financial institutions are struggling with is how to set up processes and procedures in their day to day while achieving compliance and security as a byproduct, instead of generating additional workloads.

    How can DevOps help? How does financial services companies benefit from DevOps?

    DevOps is a way to build the process and the communication between the stakeholder and all the technologies in order to automate the processes. Once you automate the process you can plug in your documentation, your policies and your pre-checks to prevent things from breaking. It’s not a person who does this – it is a process.

    What can we expect from your session?

    Understanding DevOps best practices, how they apply to the database and what DBmaestro offers out of the box to achieve end-to-end automation that includes the database.

    To learn more about database security and DevOps in the financial services industry, attend Yaniv’s session at FinConDX on Dec. 3. To check out the full agenda or to register for free, visit the FinConDX website.

  • FinConDX: The State of DevOps in FinTech

    FinConDX: The State of DevOps in FinTech

    The FinTech space has grown dramatically this year as more consumers shift their financial transactions online due to the COVID-19 pandemic.

    Financial services companies are learning how to ship better code, faster by adopting DevOps methodologies. DevOps helps companies develop fast, fail fast and learn fast so they can fulfill customer expectations and deliver quality features faster to market than their competitors. However, the shift to DevOps is not that easy.

    The digital transformation journey for banking and financial services organizations can be quite challenging. That is why, on Dec. 3, the top financial services and tech leaders in the industry will come together at the FinConDX Virtual Summit, a free virtual conference focused on the DevOps, DevSecOps and digital transformation practices and tools you need to thrive in the FinTech industry today.

    FinConDX features a stellar lineup of industry experts, including:

    • Yaniv Yehuda, co-founder and CTO at DBmaestro
    • Viktor Farcic, principal DevOps architect at Codefresh
    • Sladjana Jovanovic, vice president of payments technology, TD Bank Group
    • Shannon Lietz, director of DevSecOps at Intuit
    • Sanjeev Sharma, senior vice president, head of automation and platform engineering at Truist
    • Rosalind Radcliffe, distinguished engineer at IBM
    • Don Duet, CEO and co-founder at Concourse Labs
    • Ravi Lachhman, chief evangelist at Harness
    • Matt Wilson, senior product manager at GitLab
    • Mitchell Ashley, CEO and founder at Accelerated Strategies Group
    • Keith Murphy, senior solutions architect at OutSystems
    • Jonathan Smart, partner, business agility lead at Deloitte
    • John Rzeszotarski, senior vice president of technology infrastructure at PNC
    • Dan Garfield, chief technology evangelist at Codefresh
    • Gary Gruver, CEO at Gruver Consulting and analyst at Accelerated Strategies Group

    The virtual environment features auditoriums with different tracks where attendees can watch the sessions by industry leaders and an exhibit hall lined with booths showcasing the latest solutions from leading DevOps companies. In the exhibit hall, attendees can download resources and interact with partner sponsors including Codefresh, GitLab, WhiteSource, DBmaestro, Harness, Traceable, OutSystems and more.

    Breakout sessions and panel discussions will fall under following topics:

    • Leading digital transformation
    • Emerging technology
    • Security and audit
    • Modernization tools

    Attendees can participate in a scavenger hunt throughout the virtual environment for a chance to win amazing prizes. Participants earn points by visiting booths, watching sessions, downloading resources, networking with speakers in the chat and finding hidden objects in the environment.

    Registered attendees will also receive a link to access the virtual environment on-demand for a limited time once the live event is over.

    To see the full agenda and to register, please visit the FinConDX website.

  • How to Secure Fintech Applications and Protect Customer Data

    How to Secure Fintech Applications and Protect Customer Data

    All industries are feeling the pain of preventing rising risks to their applications, private information and customers’ data, and it is not surprising that this is especially true in the financial services sector. In fact, fintech companies on average spent more than $18 million in 2019 battling cybercrime, while other markets’ companies spend an average of $13 million addressing cybersecurity concerns each year.

    While these numbers can be depressing, a recent virtual roundtable we hosted with some of the best AppSec brains in fintech uncovered three steps organizations can take to secure their fintech applications and protect their customer data. The panel included Erick Lee, director of Security at Intuit; Jeremiah Kung, first vice president and global head of digital cybersecurity at East West Bank; and Karthik Rangarajan, security lead at Robinhood.

    The panel discussed AppSec trends, best practices for what is working in their organizations and recommendations for security leader peers who are tasked with addressing application security at their organizations. The group agreed that there’s a lot of creative thinking and exciting work happening around AppSec, and that includes across all of DevOps and engineering, not just those charged with application security. These notions can’t help but leave one feeling optimistic.

    While the spirited discussion covered a variety of topics and trends, here are the three high-level recommendations organizations should follow to best secure their fintech applications.

            1. Make sure AppSec teams are hiring software engineers. The panelists agreed that security and engineering functions should not operate as separate entities. One participant described why he hires software engineers instead of security engineers. He explained that software engineers know how to create fixes and operate at scale, which is critical for his organization, which manages 1.5 million requests per second. Since many organizations do not have the resources to hire a security engineer, particularly smaller and growing groups, it is especially important to build security into the engineering team.Organizations tend to discover scalable methods of solving problems and accelerating the development process when engineers are engaged with security. Take for example a security concern that delayed an application release. The panelists agreed that unless the issue is a show stopper, security should not delay a release, unless of course there is a compliance concern or potential violation. They recommended for developers do their thing, and let security work hard and try to keep up.

              The panelists explained this is because companies need to keep pace and release products and triage at scale. This is especially true in the fintech space, where winning business is about application features and capabilities. As an example, one panelist illustrated how his company’s focus is trying to ensure developers have paved roads so they can get “speed to benefit to customers.”

              To make this happen, his company deployed tools for automation, such as solutions that scan GitHub code for potential issues. They are also leveraging automation to monitor for security problems all through production. The punch line for them is to make security complementary and seamlessly woven into the workflow, it cannot be a secondary process slowing development.

           

          1. Compliance should be approached as an engineering problem. A significant challenge for financial services companies and fintech continues to be adhering to governance and compliance requirements. One of the reasons is a lack of automation and solutions that scale, which come at significant costs. In fact, one-third of global financial services companies spend more than 5% of their budget just on addressing compliance.Many financial services organizations rely on spreadsheets, PDFs, paper files and email chains to address and prove compliance. Fintech companies continue to address compliance questions using paper documentation and manual work. These methods are clearly not scalable and not sustainable for growing organizations to meet their expanding compliance demands.

            Fortunately, as the panelists uncovered, compliance and governance can be viewed through an engineering lens, as they have seen happen at some of the best fintech companies. One panelist illustrated that at his company he met with compliance experts to learn precisely about their problems, so his team could engineer solutions. After discovering the issues and metrics needed to prove compliance effectiveness, his team introduced automation and new tools to address the issues. His company knows the compliance methods are working if the metrics are being met, he said.

            Another panelist added that meeting regulatory compliance within a global organization like his introduces additional challenges of meeting compliance requirements in multiple jurisdictions. But the need to understand where data is and how it is being kept safe is common across the board. If you can address those questions, he said, then proving that the data is safe becomes the main task.

            For development and application security to remain sustainable, compliance cannot remain manual and human based. The panelists agreed that it’s unlikely to be able to fully automate all of the reporting and processes needed, but with a goal of 80% automation and 20% manual methods, organizations will be in a much better position.

          2. Security must be proactive. This is a common theme in our industry these days, and it certainly was popular thought the entire roundtable discussion. The panelists highlighted that fintech engineering teams are thinking about compliance and security in a variety of proactive ways. One panelist recalled that he asks his teams to “lean into security and do right by the customer before the company is asked to do so.”

      The areas addressed throughout the discussion ranged to a variety of topics, including how these days security is kept top of mind for engineering leaders during the hiring process. Participants agreed that hiring an AppSec developer is like finding a unicorn. The trick they said is to be more proactive and nurture your own unicorns internally. This can be accomplished by focusing on hiring top security developers and growing them into security roles. The result has significant benefits on all sides. The company will build its AppSec resources and expertise, and employees can value the opportunity to grow and expand their experiences into new areas they may not have known before.

      The panelists highlighted that exploring ways to ensure and accelerate approval for security features is a good way to ensure proactive security. One approach is to connect compliance issues that need addressing with security advancements. For example, if the goal to help prevent customer data loss is to add two-factor authentication, one should link a compliance issue that can also be solved by the requested security solution. Decision-makers may look to save budget and pass on simply adding security features, but it will be more difficult to say no to a compliance request. This kind of creative strategic thinking has a way of being a win-win for the company as well as its customers.

      The success of AppSec among financial services organizations depends on more than just effective security protocols that secure companies and protect customers. It needs creative, innovative and strategic ideas to enable organizations to have efficient, economical and scalable security. If that sounds like something your organization is seeking, then according to our roundtable panelists our industry has a very bright future.

  • Financial Services Rise Above in Database DevOps

    Financial Services Rise Above in Database DevOps

    Financial services, pat yourselves on the back. A new study from Redgate shows financial services have superior database DevOps and database monitoring compared to other sectors.

    Financial IT appears to outperform other industries with high-quality database monitoring benchmarks consistently. For example, financial services on average are far quicker to detect and remediate failed deployments.

    Below, we’ll cover the main takeaways from Redgate’s latest 2020 State of Database Monitoring in Financial Services report, and bring in Grant Fritchey, Product Advocate at Redgate, to better understand why the financial sector is performing so positively in database DevOps.

    2020 State of Database Monitoring in Financial Services

    Redgate has released a special financial services edition of its 2020 State of Database Monitoring Report, a study that surveyed 971 database professionals across a wide range of sectors. This financial segment report highlights how database monitoring practices within banking, investment and insurance groups compare to other industries. Here are the main takeaways:

    Frequency and Remediation

    Financial services deploy more frequently and detect and resolve issues more rapidly.

    Financial services are quickly updating their databases. Sixty percent of financial services deploy once a week, whereas 43% of other sectors deploy once a week and some (10%) only update their databases once per year.

    Financial services are quicker to detect issues and respond. For example, 49% of financial institutions detect failed deployments within 10 minutes, compared to 39% across other sectors. The average Mean Time to Recovery (MTTR) is less than 10 minutes for 32% of financial services compared to 24% for different sectors.
    [su_note]Want to learn more about DevOps in Financial Services? Join us Thursday, Dec. 3, for FinConDX, a daylong virtual event dedicated to the latest in DevOps, DevSecOps and Digital Transformation practices and tools to help FinServ companies thrive. Register today![/su_note]

    It is impressive that financial services deploy more frequently yet still maintain higher Mean Time to Detection (MTTD) and MTTR than other sectors.

    Growth and Tools

    Financial services have a larger data footprint and a higher demand for database monitoring tools.

    The survey also demonstrates significant growth in overall database footprints, reflecting the sheer accumulation of data year after year. Whereas 26% of other sectors have 50 to 500 database instances, 36% of financial services have this many. Large financial data estates with more than 1,000 instances have grown 8 percentage points year over year.

    To help track these data estates, 66% of financial services use paid database monitoring tools. In other sectors, only 39% use paid database monitoring tools. The report predicts ongoing cloud migration and hybrid cloud modes will push these rates higher.

    Sixty-eight percent of customers report general satisfaction with database monitoring solutions. Yet, financial services cite a lack of features and time-consuming processes as top drawbacks, reflecting a need for financial services to utilize advanced functions and innovate quickly.

    Database Usage

    Financial professionals perform more tasks and grant more non-IT members database access.

    Working with more rigid security benchmarks, database professionals at financial services are often responsible for an increased number of tasks.

    Across all sectors, performance optimization and backups are the most common tasks performed by 70% and 60% of database professionals, respectively. However, if we look at financial services, tasks such as optimization, availability checking, user permissions management, patching and auditing are more common, all 8% to 11% higher.

    The report also found financial service databases, on average, are more widely accessed across the whole business, including database admins, management and business teams. According to the report, this could reflect a higher skill standard across the board at financial organizations.

    Issues

    Human error spikes moderately as financial IT innovates.

    Human error, capacity problems, bad deployments and software failure are top database issues across sectors. However, human error raises slightly within financial services, to 27% from 23%.

    “This spike [in human error] is just showing how fast our financial services institutions are changing to meet the needs of a changing business environment,” said Fritchey. Though there is a high demand to fill roles with data management skills, there is a talent shortage. “Recruitment is one of the biggest challenges,” he noted.

    That said, financial services do report fewer issues in other areas. For example, database access management is handled more efficiently at financial services. Whereas ad hoc user access issues have doubled in other sectors, financial services reported no significant change.

    Looking to the future, respondents indicate cloud migration, migrating to new server versions and improving performances as the top three impending challenges.

    Why Do Financial Services Outperform?

    Data demonstrates financial services on a superior overall curve when it comes to database DevOps. But why is this?

    “The answer is pretty simple,” said Fritchey. “Finance is driven by data. Therefore, they’ve always put the time and effort into protecting that information, and monitoring your systems is a fundamental aspect of data protection.”

    The financial sector is also prone to more security exploits and data privacy issues. Such concerns amplify the need for quality monitoring.

    “Organizations with good monitoring in place either also have better security or can spot vulnerabilities faster,” said Fritchey. With such measures in place, if a breach does occur, such organizations can react rapidly.

    International regulations such as GDPR or PSD2 mean financial services must meet stringent compliances. For Fritchey, active investment in quality database monitoring is part of this process.

    “The need to be able to operate across borders means that your systems must meet multiple compliance regimes. It simply makes sense to set the most stringent standards to ensure you can easily operate in the international sphere,” he said. “Monitoring is a fundamental aspect of meeting these compliance requirements.”

    The Future of Database Monitoring

    Financial services inherently require greater fault tolerance, and database monitoring is helping such services reach bank-grade security. As most respondents estimate their deployment frequency to increase in the next year, a greater focus on database integrity will be essential to keep pace.

    The financial services sector appears to be well-positioned for continued growth. With a shorter MTTD and a faster MTTR, financial IT is significantly more advanced than other sectors when it comes to database change frequency and issue remediation.

    “The fact that those with monitoring in place are also those who can more quickly deliver value through some type of DevOps process should cause people to pay attention,” added Fritchey. “All of this combines to make for a better overall organization who does more for their clients.”

  • TechStrong TV: strongDM With Betterment

    TechStrong TV: strongDM With Betterment

    Betterment is a goal-based financial advisory company that provides robo-advising services to help customers make the most of their money, taking away all the complexities of investing and saving.

    In this interview for TechStrong TV, strongDM co-founder and CEO Elizabeth Zalman and Chris Becker, SRE manager at Betterment, joined us to discuss how strongDM helps make things faster, automated and easy at Betterment by tracking and auditing all changes on their system.

    Chris was the project lead for implementing strongDM at Betterment. During this segment, Chris shared his journey of becoming manager of the SRE team at Betterment and the reasons why they chose strongDM to secure access to their data.

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

    Transcript

    Alan Shimel: Hey, everyone. We’re back here at TechStrong TV, and for our next segment. For this segment, we have one of our semi-regulars back here, Liz Zalman of strongDM. Hi, Liz—how are you?

    Elizabeth Zalman: Hi, Alan. I’m well, thank you.

    Shimel: Good, thanks for joining us. And joining Liz and I today is Christopher Becker, SRE with Betterment. Is that correct, Chris?

    Chris Becker: Yep, SRE manager at Betterment.

    Shimel: Very cool. So, Chris, you know, I got a little background on Betterment before we started recording today, but why don’t you share with our audience—what’s Betterment? What do you guys do?

    Becker: So, yeah, the elevator pitch for us is that we’re a robo-advising platform that helps you make the most of your money. So, the idea with us is, we take away all the complexities of investing and saving and we’ve turned it into a goal based platform that lets you invest your money, save for what you’re going for, and try and make the most on top of the market and everything like that.

    So, we—yeah, we try and take all the trouble of saving and all that, we dynamically balance portfolios and things like that for you and, as Liz said, it kinda removes all the distracting stuff with money.

    Shimel: Very cool. And, you know, what’d kinda unique about it is, it’s very goal based, right? So, you gotta tell Betterment what are your goals, what are you saving for, here? I wanna buy a house, I wanna buy a car, I wanna put money away for retirement.

    Becker: Mm-hmm.

    Shimel: I wanna go on—I wanna take 180 days off and cruise around the world. That would be mine, but anyway. [Laughter]

    Zalman: [Laughter]

    Shimel: You know, so, it’s a pretty unique kind of thing like that, and it’s—I guess it’s kinda uniquely situated for, I’m gonna assume, a lot of your customer base is sorta Millennial, Gen Z kinda folks, or do you get, you know, old people like me?

    Becker: [Laughter] We have everyone, all over the gamut. I think—yeah, like, you mentioned the goal based investing, and that’s what’s super important to us. And it helps us sort of like—it helps us make the calculations about how we balance everything.

    Me, for instance, I have a goal that’s like saving for a house, and that’s a much different trajectory than something like retirement for me, based on my age and my income and everything like that. And what Betterment helps you do is just save in the best way to hit those goals. So, if you’re trying to get X amount of dollars by Y date, there’s sort of a formula that does that, and if you’re saving for retirement, there’s a different formula that works with that. It’s all kind of within our platform.

    Shimel: Cool. So—and, of course, the website, let’s get that out of the way, B-E-T-T-E-R-M-E-N-T dot com?

    Becker: You got it.

    Shimel: Okay.

    Zalman: And there’s a mobile app.

    Becker: And there’s a mobile app. [Laughter]

    Shimel: [Laughter] There’s an app. And we should also—hey, full disclosure, Liz has told me not only is Betterment a customer of strongDM but Liz is a customer of Betterment, so.

    Becker: [Laughter] Exactly.

    Zalman: It’s a great product. [Laughter]

    Shimel: Take it with a grain of salt—take it with a grain of salt. [Laughter] Anyway, Chris, let’s talk a little bit about your background, though, now. So, you are manager SRE there, and our audience is very, very familiar with SRE and SREs in general. But how does one become a manager of the SRE team?

    Becker: Absolutely. My background is particularly interesting. I guess, rewinding the clock a little bit, I was—I got into sort of computers and computer management and server stuff, like, way back in high school. I come from a pretty, I guess you could say, classical IT background. I actually have, like, a Microsoft MCP, if you can believe that, like, from back in the day.

    Shimel: I do.

    Becker: [Laughter] Yeah, Server 2003 Active Directory, so.

    Shimel: Mm-hmm.

    Becker: That’s—yeah, I went to a high school with a really great computer program that let a lot of the students get hands on access to stuff, and by my sophomore year, me and my other classmates were sort of managing our computer labs and learning about how to do all that kinda stuff.

    So, that’s like—yeah, I guess I was fortunate in that I got into this really early and it was something that I was really excited about and I was kind of like, you know, that guy in high school with my buddies, we built computers and things like that as well.

    But yeah, and then right out of high school, I went to college and studied Information Technology as well. And one of the things that, like, for me, I’ve always sort of been, I guess, the jack of all trades when it comes to technology—everything server management, a little programming, and things like that. And then out of college, I actually got a job at Warby Parker doing office support, so like, IT support.

    And that’s kind of, for me, where, I guess you could say the automation bug, I got bit by that. Because we were doing a lot of software installations and things like that on people’s machines and we wanted a way to, like, with our two person IT team scale out to support, like, you know, 300 people at Warby at the time.

    So, it was like investigating, you know, more things that we use in the SRE world today, like, things like Ansible and things like automation scripts and stuff like that. I was kind of, like, getting introduced to that as a way to just make it so that our small team could manage and automate installations on a bunch of work stations.

    And then from there, actually, within Warby Parker, I had the opportunity to change to what they called an infrastructure engineer role which, looking back on it now, it was essentially, like, DevOps, right? You know, because DevOps is, I guess, the big umbrella that covers a lot of different disciplines and stuff like that.

    So, from there, I really—I leveled up a lot of my programming skills as well, writing automation scripts and stuff to set up developer work stations. But what was important, I think, in that role for me is that I had a really good relationship with sort of internal customers, as I like to call them, for my IT role where my sort of stakeholders of the things that I built weren’t people that were the traditional customers of the business but rather those that, people that worked or the business.

    So, I think a lot of—like, one of the reasons why I like DevOps and SRE and things like that is because it allows you to have a really close relationship with your customers, because they’re in the same company as you are a lot of the time, so.

    And yeah—and then after Warby Parker, I got a job as an SRE at Betterment and our team was similarly very small. There was, I think when I started, there was four of us and we were supporting an engineering organization of around 80 folks and then, from there, our engineering team grew as well as our SRE team. And now, I’m the manager of that team and so, having been on that team for two years and change before becoming the manager, I had a really good sense of what we liked to do, things we wanted to build or our engineers and platform things as well. So, now, I’m kind of like at the helm and get to control that, which is really, really cool.

    Shimel: Excellent, man. Great story. You know what, Chris, I don’t think your journey is that unusual, to tell you the truth. I mean, I spend my life talking to people like you and Liz and—I mean, what’s different is, you know what, my high school didn’t have a computer lab, my college had punch cards. But, you know, my children, for instance, our local high school here in West Boca Community High, they actually do have, they have actually a Microsoft Certified program. So, a lot of—you know, you become Office certified, big deal, as a freshman. But by the time you graduate, you are Microsoft Certified.

    They might have, I don’t know if they’ve moved over to Google stuff now and more cloud-based kinda things, but there’s a cyber security area of concentration they call it, which is pretty cool, too. And, you know, it’s good. I mean, because so many people of my generation who—look, we took the Internet commercial, right, and built what you see here. But so many of them are self-taught, especially in things like DevOps or cyber or, you know, those kinds of things. And so, it’s good to hear people with real academic backgrounds in this stuff. I think it bodes well for the future.

    But, you know, part of what you guys are doing, obviously, is, you called it infrastructure engineering or at Warby Parker, DevOps. But the real thing here is that we’ve moved, in your lifetime, right, in your career—I don’t know if they ever had the concept of the server closet and the data center on prem. Everything is SaaSOps, right, or cloud or some sort of hybrid of that, right? There might be some third party data center you use where you’re running, let’s say, a private cloud kinda thing. You mentioned Ansible—well, that was back at Warby, so I don’t know if you’re using OpenShift or anything like that.

    But clearly, right, it’s not—this is today’s infrastructure, today’s kinda new stack as I like to call it. What about Kubernetes, cloud native, any of that stuff?

    Becker: Yeah. So, that’s like, at Betterment, we’re using Kubernetes. We’re on top of AWS as well. And I think it’s—I like that you mentioned sort of like old server clouds and stuff. I think the last time I interacted with a physical rack server was probably in college. But, I mean, I grew up punching Ethernet cables and racking and stacking and configuring, you know, Ratarays and things like that. And I think what—

    Shimel: Fun times. [Laughter]

    Becker: Yeah, right? [Laughter] Well, not with Ratarays, but I think—yeah, what I really like about sort of my, I think where my background has been really helpful for me is like, you know, when you enter this new world of AWS and cloud configurations and Kubernetes and stuff like that, like, it’s all still based on the fundamentals. And I feel like I got a really good sense of, and a really good education in networking fundamentals and things like that. Which, if you look under the hood, Kubernetes abstracts a lot away from you, but you still might have to do some kind of site or notation calculations, right? Or figure out, like, some [Cross talk]—

    Shimel: It’s been a long time since did CIDR.

    Becker: [Laughter] And it’s—and things like, yeah, and figuring out, like, we were debugging an issue with network connections and being able to Wireshark and look at the TCP handshake and figure out why we were dropping packets or getting RSTs or something like that. Like, being able to sort of zoom into those things that we don’t necessarily think about a lot these days when we sort of turn on a server in AWS and we don’t really think about—like, being able to sort of lean on that knowledge is incredibly helpful in those head scratching debugging moments and stuff like that.

    Shimel: Yeah. No, no, it’s always good to understand what the underlying technology is about. But part of what—and this is really something strongDM does, right? Part of what we’re doing here is, we want to make it chimp simple. We want it to be fast, automated, easy. That’s a big part of the SRE kinda mantra as well, right?

    Becker: Yeah.

    Shimel: And so, let’s talk a little bit about strongDM over at Betterment, right? How did—was it there when you got there? It sounds like you’ve kinda built the thing, though, you brought it in. Talk to us about the use case, here. What made you go with strongDM, why, what problem were you trying to itch, here—or, yeah, what scratch were you trying to itch?

    Becker: Absolutely. Yeah, no, for us—so, I was actually the Project Lead for implementing strongDM at Betterment. So, I absolutely love it, first of all. It’s one of my favorite apps because I don’t have to think about it ever, and that’s like—if I forget, like, it’s something so seamless and it is so well run that I forget about it, those are my favorite kind of pieces of software. [Laughter]

    Shimel: Well, no, that goes to what we just said. We wanna make it that simple, man.

    Becker: Easy, simple, automated.

    Shimel: I don’t wanna do CIDR calculations.

    Becker: [Laughter]

    Shimel: [Cross talk] [Laughter]

    Becker: Yeah, no—so, for us, we had a need at Betterment, obviously, we’re a financial institution, we have regulations that we abide by and these things, one of these things is auditability and we need to make sure that any changes to any systems that we have and that we run and we operate are auditable, it’s tracked, it’s logged.

    So, for us, strongDM was sort of like the perfect picture, because it allowed us to use that platform to get auditability, we could track and log everything as well as push everything with SSH at the time through one system, which was really nice. And it also had the added goal of not being dependent on our VPN, which we’re trying to get rid of as well, for a lot of reasons. [Laughter] strongDM, yeah, allowed us…

    And also, the thing that I’ve said amongst my team and one of the reasons why I really like strongDM is, it sort of abides by what I like to call the Unix philosophy, right? Like, it does one thing and it does it well. And it’s very predictable in its command line, it’s very predictable in the way that—its interface and it interacts with other servers and things like that. And it was really easy for us to build out this entire system with, you know, literally running two EC2 instances and they’re able to get into hundreds and hundreds of servers every day and have never had an issue, so.

    Shimel: So, Liz, five interviews—this is the longest I’ve ever heard you go without speaking. What’s up? What can you tell us about this?

    Zalman: What I can tell you is that Betterment, I think, is, I’m gonna say top three in terms of forward thinking customers that we have. They’ve pushed the envelope in a variety of ways. They were using SSH, I think, where they had requirements for how they wanted engineers to interact with SSH that we didn’t yet support in the platform. I think the same thing went for kubectl as well or usage of Kubernetes. They were the first to really stress our system—not stress our system in terms of, like, we went down, but stress in terms of, “I wanna automate stuff like this, and you’re doing this, and I need you to get to this.”

    I can’t count the number of times that Chris asked for a REST API. Have you used it yet, by the way?

    Becker: [Laughter]

    Shimel: Tell the truth, have you?

    Zalman: Have you used it yet?

    Becker: Oh, yeah—no, we have. Yeah, we used it.

    Zalman: Okay—good, good, good. [Laughter]

    Becker: Yeah.

    Zalman: They had requirements in terms of directory syncing—yeah, so, it was a pleasure to work with them. And I actually don’t recall—did we meet when you were at Warby, or were you just sort of aware of that relationship?

    Becker: You actually, I think you came in to meet the infrastructure team, like, the Ops team at Warby at one point.

    Zalman: Yeah.

    Becker: Because I remember we were piloting strongDM at one point. I don’t think I was there when the implementation happened or anything like that.

    Zalman: Oh, yeah.

    Becker: But I was familiar with the product from Warby, actually.

    Zalman: Yeah. And Alan, it’s actually interesting—Chris is part of a, Chris used to be based in New York City and in New York, there is this group of infrastructure folks that stays within sort of the B2C world in my opinion and goes to the unicorns. And it was almost borne out of Warby, some went to, like, Harry’s for shaving, some went to Peloton, some went to Betterment—I’m sure I’m missing a couple companies. And they’re almost more forward thinking than our traditional B2B clients are. It’s a very interesting trend.

    Shimel: Yeah. You know, one of my good friends is a guy named Brad Feld out of Boulder, and Brad, he founded TechStars and Foundry Group. He used to be—he’s a big VC. But he’s also an author and he’s written this whole series around what they call startup communities, and it really talks about, Liz, what you were just saying, right? Generally, you get a pool of talent, right, in a geographic region—within a community; it doesn’t have to be geographic, actually, but within a community. And that talent, it’s almost like the six degrees of separation, right? You can see a company has a liquidity event, people make money and they start other companies. Or they develop some really great expertise—in this case, kinda B2C, using real edgy kind of…I gotta stop using the word edgy, because it’s now meaning The Edge. But, you know, kind of cutting edge is what I mean—technology players.

    And they do, that—you can almost trace the DNA, if you will, right, from company to company to company because it’s that same, the same roots of people. And that’s what makes a startup community, because along the way, right, more people get added into the tribe, if you will, right? And that tribe continues to grow. And that’s how—I mean, that’s how tech centers are born, right? You can trace—like Boulder, for instance; Boulder, Colorado—you can trace a lot of what came out of, what’s coming out of Boulder by from when the storage folks were there and IBM had a big facility there and the University of Colorado and Brad coming in and investing a lot of money. There were a handful of companies that had really great outcomes or liquidity events, and it gave rise to this whole—Austin the same way, I mean, by the way.

    Anyway—strongDM. So, Chris, what are you guys using it for? Liz mentioned some REST APIs and stuff like that, but how—what are you using it for, how is it working out, what do you see?

    Becker: Yeah, so, we’re using it for, our sort of highest level use case is any time a developer needs to access a server or a database or a cluster, a Kubernetes cluster that we run and operate, they go through strongDM. And for us, like I said before, that was super important, because we want to make sure that all of the changes to our systems are tracked and audited.

    So, we have—we actually started out just implementing sort of the SSH back end, and like Liz alluded to, we had some very interesting requirements around directory services. So, we use Okta as our identity provider and directory service.

    Shimel: Sure.

    Becker: And strongDM helped us wire that together so that a person on the team, their e-mail address and their Okta identity is used by strongDM so that we can sort of tie all those things together.

    We also had, like, another thing that Liz alluded to was sort of like, we had a ton of servers and one of our unique use cases was, at the time, we were heavily using autoscaling groups within AWS. So, one of the big things with us and strongDM was that the server inventory was extremely dynamic, depending on load of our servers, depending on deployments and things like that. We might have 100 servers in inventory, we might have 200 servers. And they were coming up and down sort of all day.

    So, for us, one of the other interesting requirements is, we needed some kind of automation so that when an AWS would turn on a new server to handle extra server load that that server was automatically enrolled and registered in the strongDM platform.

    So, yeah, again, we worked with strong a lot on sort of nailing down that interface and we’ve written some automation scripts and things like that to get it to register and everything like that, and their admin, their admin token API and everything like that made that a breeze. And then our most recent implementation is actually, we use strongDM for Kubernetes. So, we basically have a, when you need to get access to our Kubernetes cluster or debug an application in our cluster, we actually live provision a container and then your proxy through strong, like, right into that container and all of that is audited as well.

    And all of our developers, actually, they don’t even—the best part is, they don’t even understand, like, they can connect to an old system or a new system and for them, it’s completely transparent. But yeah, it all runs through strong and it all is—and for our compliance reasons, that’s all audited and tracked and logged, which is great.

    Shimel: That’s nice. Two things I wanna highlight here and then Liz, I’m gonna ask you to expand on it. Number one is that, by using strong, what Chris’ team is able to do, as he mentioned, they use Okta—they don’t have to worry about hooking up this person’s identity maybe via e-mail with their Okta identity for purposes of IAM, right, across their disparate network infrastructure, right?

    strongDM here, as part of the proxy process, is lining up that person’s real identity, right, their e-mail or whatever you wanna use as their real identity with their IAM identity—I call it an IAM because it could be Okta it could be others, right? And then—but the person doesn’t have to think about that, and quite frankly, Chris, neither do you or your team, right? strongDM just makes that—again, chimp simple, easy, done.

    Becker: Yep.

    Shimel: That’s number one. Number two—and Liz, this is where I really, I’d like you to comment in—the idea of using it in this Kubernetes system and containers, as Chris is referring to, is that the norm now, or do you think this is kind of an advanced use case?

    Zalman: It’s an interesting question. And yeah, I think to your first point, it’s, we’re acting as an infrastructure API, right? We don’t care what Chris is using as his identity store. We don’t care where his infrastructure is, we’re just connecting the dots.

    Shimel: Yep.

    Zalman: Kubernetes was—I mean, we’ve seen different instantiations of Kubernetes over the years, right? Docker tried with Swarm and it didn’t stick and Kubernetes did. And maybe people were using it, they were trying it on. And I remember, like, the month that it hit production workloads, because I think we got seven or eight requests in one week. It’s like—why don’t you have support for this protocol? And we said, “Okay, time to build kubecl support.”

    Shimel: Time to do that, yeah.

    Zalman: Yeah.

    Becker: Yeah, guilty. [Laughter]

    Zalman: Yeah, you were one of them. [Laughter] It was like plain, plain, plain, plain, plain—mainstream. And so, I think everybody is trying to find some way to systematize and puppeteer everything that’s going on and abstract away a lot of complexity.

    So, no, to me, Kubernetes is certainly here to stay. I see everybody using it.

    Shimel: But is their—because it sounds like their Kubernetes installation, if you will, the way they’re using strongDM is maybe a little different than—is that the standard way that people are using strongDM and Kubernetes or is theirs a little different?

    Zalman: I think Betterment has a particular approach to locking down access which is, you literally get this much access or this much access or this much access or over here, maybe this much access. It’s highly tailored and fine-tuned, and I think that is the—that’s sort of the forward thinking way. Like, people talk about lease privilege and Betterment has actually implemented it across the board for every single thing that somebody needs access to.

    Shimel: That’s great, man. That’s—and Chris, kudos to you and your team for that, right? Because that is—look, you’re in the financial industry, you’ve gotta do what you’ve gotta do there, but that’s an excellent thing.

    Guys, we’re over time, to tell you the truth, but I kind of enjoyed the conversation today, so I let it go. But we need to break out of here. Chris, enjoy—I know you’re about to take, you said, like a week off over that at the shore and enjoy it. I see maybe you’ll get that oar off the wall and actually do something.

    Becker: [Laughter] Some paddle boarding.

    Shimel: Yeah, that sounds cool. Anyway, I’m just thinking, I’m supposed to be going out on the boat tomorrow, but it’s also supposed to rain, so I’m not sure. But anyway, enjoy your week off. Thanks for joining us, thanks to Betterment for allowing you to tell your story here today.

    Liz, always a pleasure to have you on and hear more about strongDM and this whole kind of—you know, these new companies, not necessarily new like today new, but a new way of doing things and a new way of making it easy to bring people on and access assets wherever the infrastructure is, so—fantastic.

    We’re gonna wrap. This is Alan Shimel for TechStrong TV. We’re going to be right back with our next guest.

  • Financial Services: Future Proofing Your Digital Transformation Strategy

    Financial Services: Future Proofing Your Digital Transformation Strategy

    The Financial Services: Future Proofing Your Digital Transformation Strategy virtual event will explore the state of development and DevOps in the finance industry, and how organizations can digitally transform their strategy in order to release new, compliant applications and safely adapt to change at any speed demanded by the business. The virtual event will take place on July 9 at 2:30 p.m. CEST (8:30 a.m. ET).

    CloudBees is bringing together a stellar line-up of thought leaders to discuss the impact of digital transformation in financial services, including:

    • Sacha Labourey, CEO of CloudBees
    • Jost Hoppermann, VP and principal analyst at Forrester
    • Chafin Bryant, software engineering manager at Capital One
    • Keith Blizard, SVP of public cloud services at Fidelity Investments

    The experts will discuss the challenges the financial services industry faces in adopting DevOps.

    At the Financial Services: Future Proofing Your Digital Transformation Strategy virtual event you will learn:

    • How to assure separation of duties and access controls without stifling innovation.
    • About Capital One’s DevOps success story and how they’ve tackled some of the unique challenges of CI/CD in the finance industry.
    • How to incorporate legacy and hybrid technology into your release trains and processes.
    • How to scale across geographies, teams, applications, regulations and environments – and still get the velocity and reliability expected by the business.
    • About Fidelity’s cloud transformation journey and CI/CD best practices.
    • How to build bridges across devs and ops; employees and contractors.

    Join the CloudBees community and learn how to future-proof your digital transformation strategy. To check out the agenda and to register, visit the Financial Services: Future Proofing Your Digital Transformation Strategy website.

  • 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

  • Why Banks Must Ditch the ‘Build vs. Buy’ Mentality and Embrace a Platform Approach

    Why Banks Must Ditch the ‘Build vs. Buy’ Mentality and Embrace a Platform Approach

    The past decade has seen digital transformation change nearly every aspect of our lives, and banking has proven no exception. Indeed, proprietary data from Avoka shows that in mid-2017, mobile overtook desktop as the most popular channel for applying for new deposit accounts at one top 10 U.S. bank. Banks have accordingly ramped up their IT departments and technology investments to adapt to this brave new world and digitize their offerings, with the aim of making their financial products just as accessible and convenient as products offered by tech customer service giants such as Amazon.

    The push to make banking products digitally ready (and very quickly) has spurred the old “buy versus build” debate in bank IT departments: Should we build our own digital onboarding software from scratch in-house, or do we buy off-the-shelf solutions from third parties that may be generic and not customizable to our brand and product offerings? While this dichotomy may have been a suitable mentality years ago at the start of the digital transformation revolution in banking, it no longer fits with the reality of today’s more complex development landscape and is starting to cause significant problems in bank IT departments.

    It’s no mystery that the majority of today’s banking IT projects use elements of both “build” and “buy.” But banks tend to opt for the “build” option in the main, reasoning that in-house development drives better outcomes. But this is a serious misconception—recent research from Forrester shows that more than half of all banking customer experience projects take longer than expected, leading to a blown project budget an overwhelming 88 percent of the time. A critical point: Projects using or re-using internally built components are far more likely to suffer these issues.

    This inevitably leads to a spiraling buildup of technical debt—a concept that banks should familiarize themselves with and treat just as seriously as actual debt (after it, it ends up in the bottom line—total cost of ownership is higher for internal builds around 64 percent of the time, as per Forrester’s research). A snowball effect takes hold: Projects with problematic delivery are far more likely to require endless catch-up fixes and high maintenance costs, draining time and resources from the development team that otherwise could be put to use on the increasingly crucial work of updating the offering to meet the continually evolving needs of the market and customers. On average, one-third of customer-facing software releases are updated only once a year or less, a number that rises closer to half for projects that are over-budget.

    Forrester’s research shows that this isn’t a matter of under-resourcing; teams report being allocated the right amount of time and resources. Rather, stumbling blocks stem from architectural inflexibility and poor technology, as well as changing business priorities sapping stakeholder enthusiasm and project velocity.

    Neither “build” nor “buy” in the older sense of the two approaches provide an adequate strategy for today’s development environment. The aversion to buying mainly took hold during a period when third-party products were fairly self-contained black boxes—off-the-shelf offerings that provided none of the flexibility of in-house and came at a cost to branding. However, this is no longer true of the third-party vendor landscape. The advent of platforms and APIs means it is now far easier for banks to bring in multiple fintech integrations to fill the gaps in their offering in a modular, “mix and match” manner—all fully customizable, extendable, flexible and capable of being brought together on an organized, neat platform.

    Banks need to embrace this change and ditch the old “buy versus build” debate that so often prioritizes internal builds as a knee-jerk reaction. The constraints of the old build or buy choice means that the tendency is still to think of digital transformation as a series of off-one projects, when the most successful efforts treat it as a holistic, continuous evolution. After all, customer needs and expectations are constantly evolving, and so should customer-facing software.

    So, how should bank development teams and their stakeholders approach a new digital transformation project? The answer lies in BBEA: Buy, Build, Extend and Assemble. The rule of thumb here is that where services and capabilities are generic and not unique to the bank, they should be sourced from expert vendors with a proven ability to get the job done quickly and in an expert manner (why incur a longer development cycle and higher TCO by reinventing the wheel and building internally?). This frees up the bank’s own internal resources to work on building elements that are truly unique to the bank’s value offering. While it used to be prohibitive to pursue both of these approaches simultaneously, this is precisely what the new world of APIs and platforms enables.

    Sourcing and extending components in this way reduces technical debt significantly, and spreads the cost of R&D across external players. The platform approach makes it far easier for banks to tailor these external components to their own brand and specific circumstances, and makes adaption to changing future needs far less onerous, removing the tendency to revert to big and costly start-from-scratch projects on a regular basis.

    Banks that want to get ahead in their digital transformation strategies must their ditch old development habits and embrace the new platform approach. Buy vs. build is dead; long live BBEA.

    — Steve Demchuk

  • 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