Kevin Montalbo

Welcome to episode 54 for the Coding Over Cocktails podcast. My name is Kevin Montalbo. Our guest for this episode is known for delivering large scale technology solutions over the last thirty (plus) years as both a consultant working with, and as an executive at, large banks and global insurers.

He has implemented APIs, microservices, AI, Machine Learning, and payments solutions to help financial services firms accelerate their journey towards Open Banking, Open Payments, and the Digital Ecosystem.

Most recently, he has focussed on designing and implementing data mesh solutions to enable real-time data access in support of AI/ML solutions, Open Banking, and mainframe modernization transformations.

Eric Broda

Hey Kevin, thanks for having me!

Kevin Montalbo

All right, so before we dive into the details of what's driving Open Banking in Canada, can you shed some light on what Open Banking is and how it's bringing more innovation to the banking industry?

Eric Broda 

Sure. First off, I think everybody knows we all buy stuff and I think everybody or most folks have a bank account or a credit card and some of us even trade stocks. In each case, what we have is banks help us do this and today for this service, we let banks own and control our financial data. So simply put, they're the only player that can decide what to do with their data, who can use it and who can share. 

So, is this a big deal? I think it is. And I think the UK Open Banking regime, they published a report recently and that prior to Open Banking, they found several things: poor service and little competition. And with little competition, little choice. And with little choice, [there] is no innovation. So, [it’s a] pretty stark situation and that's why they introduced Open Banking. So, I'll talk a little bit about Open Banking in the UK, primarily because it's one of the first and probably the most well-known examples. But Open Banking in the UK specifically addressed these issues. It provides a framework and consumers and businesses can authorise third-party financial service providers to access their financial data. 

What this really means is that Open Banking gives you control over your data and allows you to have a say about how it's shared and how it's used. So for example, you can go to a third-party investment, fintech, for example. In Canada, there's a bunch of them in our premier at this point, you can use them to access your account and provide better financial management services than your current bank Or maybe you're a small business and you don't like the cash management services that your current bank is providing, you can go to a fintech or another large player like Intuit with Open Banking and sign up for better cash management services. 

This is really just a small sampling of the capability – if you look at the UK environment, you can see there's really a huge change in the competitive landscape. So, now to summarise, you know, Open Banking really provides several benefits. Customers get choice. With choice comes competition, and with competition comes a level playing field. With a level playing field comes new companies that offer better services, reduce costs and new products and these new companies provide and create tons of new jobs. So, that's the real big deal. And that's why this is such an important thing.

Kevin Montalbo

Yeah, that sounds great. And this trend towards Open Banking is now gaining global traction obviously. So, can you explain to us how it evolved from a European regulatory model to something that is now seeing international adoption.

Eric Broda 

Yeah, sure. Modern Open Banking, I would say, probably started with PSD2, which is the payment service [that] directed the second iteration out of the European union in 2018. Now the goal of PSD2 was really to offer customers choice regarding banking providers. And as I mentioned earlier, was that choice, competition, innovation, better service, et cetera. That was kind of the starting point. 

But the UK quickly extended this beyond the payment origins and went into broader financial data and account sharing. And then Australia went even further and used Open Banking as the first of the vanguard of an open industry approach to believe that things like Open Telecom and in Open Energy. 

So you can definitely see that there's some pretty significant momentum. Now, the thing that's interesting about each of these approaches is that they were established as a result of a regulatory imperative. Now, other regions such as the US, are notably taking a little different approach, taking a much more laissez faire approach, allowing the market to determine the best approach. So far, they haven't provided a true Open Banking solution, but rather a solution is clustered, kind of depending on perspective, I suppose, fragmented, around larger banks. 

So, you know, we see an ecosystem, perhaps to use that term forming around large banks like JP Morgan and Wells Fargo. Simply put, I'd say that the jury is still out on which approach is better in the long term, but obviously the regulatory approach has definitely produced some clear, early stage, wins.

Kevin Montalbo

So, you're a very active writer. You've written quite a bunch of articles on your Medium account and you have previously written about how Open Banking solves a number of issues, including screen scraping. So, what is this? And how does Open Banking prevent it?

Eric Broda 

So screen scraping is really where technology actually looks at websites and then parses those websites trying to look for key information – and they use that to provide banking services. So, they don't actually integrate with your bank. They take the bank's website, parse it, and try to provide some services that mimic what the bank does. The problem with that is in order to do it, you have to actually share some pretty confidential information, your username and your password. You have to share those with third parties. 

Now, if you think about that, that's a pretty big deal. First off, you know, your username and password that provides access to all of your financial data and allows folks to actually do stuff with that financially -- it’s stored in the third party. All you have to do is take a look at the newspaper. You saw Capital One a few years ago. But in Canada, even Desjardins banking provider in Canada had data leakage. 

So really, my first comment would be that it's probably the wrong place to store sensitive data and it especially requires a lot more due diligence. Now, that's not to say that third parties don't do the due diligence, but it's a lot of work. And if every single party has to do that due diligence, it's really gonna slow down – aside from the security issue –  it’s gonna slow the adoption of this type of capability. So, that's kind of the first thing. 

The second thing is, and I can't speak to whether it's the same outside of Canada, I suspect it is, but the contracts – banking contracts that people sign up for in Canada specifically do not allow third-party access to your bank data. And they definitely do not allow you to share your username or password. So, really what that means, and this is actually echoed in the Government of Canada Report: the real issue is if there's a financial dispute, or worse, loss that occurs as a result of third-party negligence. You actually have no recourse. 

So, this is a really, really big deal. And interestingly enough, the Government of Canada put it in the report, and they highlighted that one of the key opportunities as a result of Open Banking is actually eliminating screen scraping. And they highlighted this because what they found is through surveys and other means, the customers really don't understand the material risk and liability that they're actually undertaking. So screen scraping is a solution that has worked in the past, but customers were oblivious perhaps of the risks and the liabilities. But there's a real opportunity, as to what the Government of Canada has said, around Open Banking fixes.

Kevin Montalbo

Yeah. So, since we're talking about the Government of Canada and how they're approaching Open Banking, how does your approach to Open Banking differ, as compared to other Open Banking regimes in the world?

Eric Broda 

Sure. I would say that there's probably a few different dimensions to that question. But first, I would say that they're taking a relatively low risk in a highly regulated approach. As I mentioned earlier, there's different approaches for that, but ultimately they're taking a very low risk approach. So to start with, the Canadian government is only addressing core banking information. But even within this context, it is taking quite a broad view: services are targeted, individual consumers, as well as small businesses. There, including a broad swath of the financial services community, including Canada's largest federally regulated banks, but also, its smaller, provincially regulated credit unions. There's quite a few of those, as well as accredited fintech. 

So, it covers just about all of the financial players in the community and not just the big, but also the small and everything in between. Last but not least, it includes investment products, explicitly highlighting things like stocks, bonds, mutual funds, et cetera, that are included under this, within the scope of these Open Banking APIs.

So I think that's kind of interesting. The next part I would say is that from a scope perspective, Canada, [as] I mentioned earlier, it's low risk. And in some ways, I think maybe it's appropriately cautious. So, if you think about Australia, they have what I would characterise or call as an open industry approach where they're gonna do Open Banking. Then they're gonna go and do Open Telecom and apply the same principles to Open Energy and a few others. There's nothing like that on the agenda for Canada. And I think maybe that's a good thing. Maybe we gotta be tackling Open Banking before we start to go into other industries. 

But you know, I don't want to critique the Australians. Kudos to them for going big. But that's not the approach Canada is taking. The only other thing I would say is perhaps there's one area where Canada is a little too cautious and that's around payments. So, payments is a pretty well established domain. Open payments is working quite well in the UK and in the EU. Because of Canada's caution, we're not including payments within the Open Banking remit, which really means we're gonna be late to Open Payments and some of the innovations around requests-to pay-that you see in the UK and EU market. So again, just to summarise, some little low risk, perhaps some caution – warranted caution. And then perhaps, you know, some areas where they could go a little bit bigger.

Kevin Montalbo

All right. So let's dive into the technology aspect of the space. Obviously, there's a lot of technology going on behind Open Banking and I'm very curious -- what role do APIs play in enabling Open Banking?

Eric Broda 

Sure. Well, our listeners probably know what APIs are. But I'll kind of summarise and simplify. They provide the language and grammar by which apps, systems applications talk to each other. So, banking APIs are the language and grammar, the apps systems and applications talk to banks. The problem with these banking APIs is that they're closed. What that really means is that the banks don't share their language and grammar. Effectively, what that means is every bank has its own language and grammar and there's no translator for that bank's language. So, it's only your bank who knows that specific language or dialect or grammar [that] can write APIs for themselves or extend their apps. 

So, what does this really mean? If you're a developer that wants to create a cool app to consolidate from multiple banks, you can't do that. And that's a problem. That stifles creativity, competition, and choice. So now, if you look at what regulatory regimes want to do, they want to open the previously closed banking environment. They want to introduce an Open Banking language and grammar. And this is where Open Banking API has come into play. They define the specification, or again, the language and grammar that all banks must conform to. And this will make it easier for developers to build apps that work with many banks or at least those subject to the regulatory regime.

Kevin Montalbo 

All right. So, speaking of APIs, you've recently written that there is a need to rethink the enterprise API lifecycle because of today's competitive market. In your article, you detail some steps on how to radically improve API delivery speed. So, can you take us briefly through these steps?

Eric Broda 

Yeah, sure. So, I've been building large and complex APIs for banks, insurance payments providers for many many years. And one thing that is absolutely clear is that organisations seem to use a one-size-fits-all lifecycle for software delivery. And this usually means that the life cycle is absolutely not fit for purpose, which really means, you know, many times it's far too slow, costly and perhaps overly manual. 

What does this mean from a business perspective? It means products are going to market slower and they’re more costly and leading to lost revenue, lost opportunities. APIs offer a unique opportunity, obviously as most of the listeners probably know, to radically improve speed and agility, recognising the role of APIs as key enablers not just [in] Open Banking but the broader digital ecosystem. I would argue that it's not just practical, and feasible but absolutely necessary to rethink the API lifecycle and figure out exactly how we can tune it to optimise for the opportunities that APIs present themselves. 

So, there's a few ideas that I've written about at length. So, the first one is recognising that APIs are defined by their specifications. These are kind of the core artifacts that are used throughout the cycle. These specifications in many cases are handcrafted, in some cases, sometimes generated from the code. But ultimately, through their artifacts that are throughout the lifecycle, these specifications should be decomposable. They should be cataloged and they should be able to be recomposed. So, that's kind of the first thing. So, these API specifications typically, again, OpenAPI specify the contract for APIs. These APIis getting decomposed into sub schemas, these sub schemas can be used by developers in building other APIs. 

So, the most obvious ones I think that most people would recognise is if you look at an OpenAPI specification, you don't want to reinvent the wheel on error codes. They're all the same and you ought to have consistency for those response messages and request bodies are all very very similar. So these components ought to be defined correctly once, or better yet they should be decomposed from existing well-working specifications. So, once you decompose these, you now have artifacts that can be put into a catalog. They can now be found easily, consumed and reused. 

Now with these API specifications, now that they can be found, they can be recomposed into new specifications. And this is a really big deal because now, as you recompose specifications, you're not going through the test-debug cycle, the business definition cycle for all these reusable components and ultimately, you can deliver API specifications faster with greater agility and ultimately, with huge cost savings. Pretty significant based on my experience. 

Now, the second piece of the puzzle is the API lifecycle instrumentation. So, in many cases we often talk about APIs being an instrument to attunement metrics, logs, creates the information. That's cool. That's necessary. But that's not what I'm talking about. Rather, I suggest that we instrument the lifecycle and gather, organise and catalog all the digital exhaust that comes when we actually build APIs and have them go through their life cycle. 

So, really the question is, if we could capture all of this digital exhaust, why wouldn't we want to store it in the same catalog where we store the API specifications? Then we'd actually have an API marketplace that contains all data about an API. Now, think about this. If I can search and find an API and discover its specifications, code, test cases, test results, Dockerfile, Kubernetes, these are all things that get admitted through the API lifecycle. What would I be able to do? I can actually have all the information about an API at my disposal. And that's a really, really big deal, I'll tell you. That in and of itself makes it faster and easier to deliver and build APIs. 

But there's even an additional benefit. And it really leads to what’s traditionally called API governance. I really don't actually like that phrase. I like the phrase “API certification'' for a bunch of different reasons. First off, I have never found a developer that enjoys the governance process in any organisation. Even in the most advanced shops, I still see physical or perhaps today, virtual  governance meetings to determine if an API is ready to move from development to testing or from testing to production. 

So, ultimately what we ended up having  is pretty well-intentioned and smart people revealing artifacts and probably offering some high level questions. But in the span of a single meeting, most of this dialogue is superficial and complete. It's largely based on opinion rather than fact and ultimately doesn't add a lot of value. In fact, even in the best cases where I've seen API  governance in general, perhaps, where it actually works only in the best cases, it actually catches gross negligence or oversight. 

So, I'd like to offer a different scenario for that. And it's really enabled by the previous two points that I mentioned. So again, let's assume we have the API marketplace populated by all necessary artifacts. Now, what if we provided machine readable checklists. So, it's a really simple, perhaps a JSON file that defines what API life cycles are required at what stage and what constitutes a pass for governance purposes for each stage of the API lifecycle with a little bit of automation. I'm not talking about locks. I've done this before. Each item on the checklist can be interrogated. It sets an offer to pass or fail grade and is registered again in the marketplaces catalog. And now what if this governance status was available and current at any one point in time? Now, governance meetings can be fact based. When you go to the governance meeting, everybody looks at the API marketplace, looks at the API, looks at its governance checklist and they can actually see all the information available all in place. Now, at least they can make fact-based decisions. 

Now, interestingly enough, what I've seen is, for at least the early stages of the life cycle, once this data API lifecycle information is in the catalog and becomes trusted that even the governance meetings, the API governance meetings, the ones that everybody hates, can start to be eliminated. Now, I've never seen anybody go – at least the clients that I've worked with –  there's always been a point where they want to have that field before. Something goes into production. What I have seen is in many organisations, they can get rid of many of the governance meetings and automate those, with this approach and again, the net result is that, what you get is tremendous speed improvements resulting in cost improvements, cost reductions, like this is actually a really big deal. 

Unfortunately what I've found is I've had to build each of these pieces in parts, assemble them in parts, there's no real product that does a lot of these things, but this should be well within the the remit and capability of a fintech or API  technology firm to assemble the parts and make this a product thatI know, for one, my clients would love.

Kevin Montalbo

Interesting idea there. So, I want to go full circle now since we've been talking about Open Banking and it's been opening several pathways, Open Banking to digital transformation. But apart from this, one could argue that the pandemic was also another catalyst towards this digital transformation. So, looking back, and based on your personal experience, do you think companies took advantage of the time during the pandemic when it hit to digitally transform themselves? Or were they just really responding to a one-off event that forced them to implement protocols for remote working and remote customer service but missed the opportunity for true digital transformation?

Eric Broda 

Yeah, I had to give this one quite a bit of thought. And you know, I say my response would be, with the benefit of “2020 hindsight” as they say, so if I were to use my way back machine and look in the past, I would probably say that most organisations were caught flat-footed by the speed and impact of the pandemic. Simply put, technology spending needed to radically increase in vision. Business and issues needed to be radically reprioritised and all this had to be done at a pace that none of them were really accustomed to. 

So, if you think about, like you mentioned a few things, the confluence of events that they had to deal with, a completely new remote work culture, required everything, with network upgrades to identifying new ways of working the whole the widespread rise of the digital ecosystem, the electronic supply chain, even in financial services, we see that has made enterprises realise that they truly needed to reprioritise and dramatically accelerate their technology and in particular, the API and integration efforts. 

You know, I think this ultimately radically changed the enterprise decision making process, business and IT now sit at the same executive table. Business decisions are IT decisions and vice-versa. And I see the executive team now, they're starting to realise that they really need to have some serious technical chops. Now, the nice thing about this is I think this is a lasting result and I think we're going to see this mode of operation going forward.

Kevin Montalbo

All right, I know you work for a confidential company, but do you have  –  somewhere in your mind, an organisation that, you know, embodied this true digital transformation?

Eric Broda 

Yeah, you can kind of look at my LinkedIn and figure it out but I'm not not at liberty to actually mention any of their names. But if you take a look at it, I would say there's definitely been some of those clients that have absolutely, positively lived the digital transformation now. The interesting thing is that one client, again, they have to remain nameless, had a digital transformation initiative well underway before the pandemic. But what we found is there's a confluence of all these things we talked about but more, the thing that I found most specifically interesting and enlightening was this digital supply chain. 

And what ended up happening was, we were timed just perfect at the start of the pandemic. Actually my team - myself and my team - we're implementing the API platform, the Kafka platform and a bunch of other things related to that. And what we found is that there is a very early recognition of APIs, event management, just as a few examples. There's a variety of others. We're going to be core to actually addressing this, the rise of the digital ecosystem. 

So they invested, They doubled-down in effect to radically accelerate their digital transformation. And the bottom line is it has paid huge, huge dividends. It directly led to millions of dollars of new deals. It has led to a pretty seamless transition to the remote workforce and I think it's really changed the culture of the organisation, to recognise that technology and business decisions really are made together. Like I said, there's been huge, huge benefits as a result of that. So the pandemic caused a ton of problems. But I think, you know, one of the side effects unintended, perhaps one of the beneficial side effects, is that it's really energised the recognition that technology is core and fundamental and central to these organisations. And it's shown that for those that have invested, there are true returns on the investment and they're quite substantial. And I'd love to if I could take credit for all of that, but really, this is about some pretty wise and forward thinking CIOs and CIOs and CFOs.

Kevin Montalbo

Yeah. Speaking of CIOs, CEOs, CFOs – and you know all the people in the C-suite where, should digital transformation ideally begin within the organisation in order to drive effective change? Because you know, you talked about how business and IT are now sitting in the same boardroom. So, is it the CEO's responsibility to drive down that kind of initiative? Does it come from the board of directors? Does it come from operators, even, from the ranks?

Eric Broda 

Yeah, that's an excellent question. Let’s kind of unpack it.  First off, I kind of mentioned earlier, but in every industry of all sizes, every enterprise is a digital enterprise. They participate in an increasingly digital ecosystem. And I think most industries are starting, most firms are starting to realise that. And I think you've even seen research from great firms like McKinsey that have shown that firms that aggressively digitise are far ahead of their industry competition. 

Now, if you look at even the largest companies on earth: Apple, Microsoft are all digital. And in fact if you look at this, the car that I drive or other folks drive that car, most people don't realise it, has more software in it than, you know, some banks. We have more power in our phones than data centres did a few days, at least when I started my career a few decades ago. So really what this means is that you know, digital transformation, the act of becoming more digital, is now a fundamental enabler of success. And as such, it needs to become part of our DNA 

So now the last thing I mentioned, before I answer your question, as context, digital transformation is not a quick endeavor. It takes years, a huge amount of willpower and a huge amount of funding. It was so much riding on becoming digital and you know the heavy boulders that you have to actually move, there's really only one place where that's gonna be organised and led and that is the CEO, the chief executive officer. There's no one else that can reorient an entire firm towards a digital journey. There's nobody else who really has the power to drive major change. There's no one else who can sustain that type of change for multiple years. And since the CEO reports to the board, she will need to convince the board and secure the necessary funding for change of this magnitude. 

So the simple answer is, a true digital transformation is driven by the CEO. But while the drive, the vision comes from the CEO, there's a number of partners that need to play a significant role to make this happen. The CFO needs to understand why this is important to provide the funding, if you will. The CIO needs to be able to mobilise the technology resources, to implement that vision. There's a variety of other partners that need to participate but at the end of the day, it really comes from the CEO.

Kevin Montalbo

Eric, you're at the thick of change within organisations and even through Open Banking over there in Canada, how much of a cultural change is digital transformation?

Eric Broda 

I would say it's a very significant change. In fact, I don't think you can do any digital transformation without a change in culture and I think a changing culture really boils down to a few things. One is, obviously the first is the organisation may need to change a little bit. I've seen that actually be required in a number of places. I think the other part is [that] attitudes need to change and not in a negative sense. In fact, I think most people that I deal with, whether it's the developers or the CEOs, CXOs, there's all a will to change but that will need to be commenced with an execution ability. And what I think that I found out, what I've seen is there needs to be a culture change that says, “I can wait for things to happen” to one that says “I'm going to be bold and aggressive and take the lead,” becoming a leader or at least a fast follower as opposed to a late follower or a laggard. 

And that's the true cultural change that needs to take place. I think, you know, that leads to a bunch of other things. I know a lot of folks are moving towards the Agile delivery model, there's still a lot of big firms that are stuck in the waterfall model. Sometimes that's appropriate. But ultimately, even the way we do IT needs to transform from something that is relatively slow, stable to something that is a little more agile. 

The last thing I would mention, culture relative to culture change, I think it's the ability to accept and embrace risk. That's not to say we accept and embrace crazy risks. What that means is I put in the guardrails to recognise when I'm going off base or off track so I don't go off the ditch but rather I can course-correct relatively quickly, easily but with those guardrails in place, be able to take risks and reap the rewards of those risks. 

So, I think those are some of the cultural changes that I've seen with my clients. And I suspect that's not common to just my clients. That's the culture change [which] I think is seen in the ones that truly do successful digital transformation.

Kevin Montalbo

All right, Eric. You've been great at distilling all this information and facts with your insights and opinions. I'm sure our listeners would love to pick your brain. Where can they follow what you write and what you do?

Eric Broda 

Sure. I'm active on Medium.com. So, just do a quick search on “Eric Broda,” very active on LinkedIn. So that would probably be the second place that I would go to. Each of those have a way to message me or provide some feedback, so that would be the ideal way for me to interact with the folks that are interested in me.

Kevin Montalbo

Eric, thank you very much for joining us for Coding Over Cocktails. I hope you had a grand time.

Eric Broda 

I did Kevin, thank you very much and hopefully we can talk again in the future.