Charting the Course for Future Payment Technologies: Insights from Craig Borysowich

Craig Borysowich has over 30 years of Technology Consulting experience with both public and private sector clients, including over ten years in Project Leadership roles. Craig has an extensive background in working with large-scale, high-profile systems integration and development projects that span throughout a customer’s organization. He has an extensive background in designing robust solutions that bring together multiple platforms from Intel to Unix to Mainframe technologies with the Internet.

Host:

First, let me introduce you. This is Craig Borysowich. He's the director of Enterprise Architecture at Payments Canada. Payments Canada, as the name sounds, is the underlying organization and manages all the payments within Canada. I'd love for you to correct me and talk a little bit more about what Payments Canada does, and I guess into greater detail to explain to the audience what you do.

Craig Borysowich:
Yeah, Payments Canada provides the interbank account-to-account transfer rails. So we have AFT, which is a file exchange process between the banks to exchange payments and replace an old magnetic tape shipping model that was used before. And then there's a batch, a tabulated version of that for lower priority payments. So we basically just stack the exchanges together, do a tabulation, and at the end of the day, we settle between the banks.

And then for high value, we have our Lynx platform, which for transactions bank-to-bank that are over fifty thousand dollars, they go through the Lynx platform, and it's also connected to the SWIFT banking system. So the international banking transactions usually traverse that rail as well. And at the moment, we're in the midst of building the real-time payments rail, working with both in Iraq and Vocalink MasterCard.

Host:
Okay. I'd like to go through each of them, one by one, just to get a better understanding of them, you know, how they work and why they work the way they do. So, I guess the one that is most familiar to most people is the... when I looked at a message type, which is, I think, SWIFT. So that's one of the most people use for transfers.

Craig Borysowich:
Okay, go ahead. Yeah, so SWIFT has a specialized messaging set for doing the bank-to-bank transfers. And it's currently called the MT, message transfer, protocol. So there's a newer version. The banking system is in the process of kind of modernizing and transitioning to the next generation of the message set, which is now called the MX message set. So we're going from message transfer to message exchange in the naming title. But the new message set is ISO 20022 compliant, and so it's got... it's a bigger message. There's a lot more fields, more information around both the sender and the receiver of funds. So, it's a much more robust transactional capability, and it will help banks better evaluate if the beneficiary of funds is, you know, if there's potentially illegal activity going on or known active issues with the accounts or the account holders of the receivers and the senders. So hopefully, this will broaden our ability to battle some fraud in the system as well.

Host:
If we go back a little bit and talk about the two different types of MT and MX, you said, "Hey, look, MX has a little bit more information, and that way we can, you know, I guess a little bit more metadata." And then it allows us a better understanding of the sort of, I guess, the information that comes in clearly. But if we, you know, sort of go back to MT, is there something structural there that is different from MX, apart from, you know, there's more data to find with MX? But is it something structural in the way that information's sent, where MX is a bit more secure? Can you talk a little bit about that? Or is that the right direction, basically?

Craig Borysowich:
Yeah, I mean, so both of them come from, you know, ISO-based standards, so there are standard message formats for both sets of messages. And then, you know, very specific details around the content. That goes into each of those fields and that way as we move from you know a banking system in one country to a banking system in another country where maybe they label things slightly different, the assistance with ISO 20022 and the broader fields that are available is that there’s better definitions and data dictionary content around what each of those fields are for and what’s supposed to go in there so there’s a better international understanding of the different data that’s being exchanged. That way, they can better match where it belongs in their banking systems and also better understand codes and the error codes that are used internationally.

Right, and that does that imply that just sort of implicitly improves the security as well simply because there’s more information so the security of Swift and how they encrypt messages and all those things that’s kind of separate from the actual messages themselves? I think it’s more about that more robust data content that just basically allows both the sender and receiver to do deeper analytics on who’s involved in the payment. So things like ultimate beneficiaries and other sorts of details are included, so all the steps to get from one account to another, all of the banks that are involved are included now in the message. Whereas in a number of cases, they would pass through a message, you wouldn’t necessarily know that they potentially handled the message, so all of those things are covered in the MX message then. So it’s almost like you’re sending them in the message is almost like a paper trail, so there’s no opportunity for, you know, bad actors to fake anything essentially, and that’s where the security comes from.

Host:
Okay, part of it. Fair enough. So is there sort of is there a limit to that? Is there, or I guess is there sort of a limit to how many banks or how many institutions, you know, sort of something can pass through? So therefore there is a limit to what the size of the message will need to be or does it sort of like, let’s say it passes through every single bank in the world. Is that possible with MX? I would assume it would be possible if every bank had to touch a particular payment message and then it would certainly stack all the details into that message because each one is kind of appended as an independent document to the header. So, I mean, yeah, it would be possible, it would be a crazy payment. It would be crazy payment obviously, but you know, typically there’s anywhere between six and ten banks involved in international transactions. You know, typically with domestic, even in a domestic payment there could be up to four banks because we have direct participants and then indirect participants on links. So for the most part, there’s probably up to four banks for a domestic payment if it’s going between two indirect banks with two different direct clearers on links.

Craig Borysowich:
So, uh, let's talk a little bit about the, I think, AFT payment processing, automatic funds transfer. So could you explain what that is to give the audience a better context of that?

Host:
Yeah, absolutely. So it’s really just, we have a private network and we allow the banks to exchange files with each other and, you know, back in the old days they used to ship magnetic tapes for the mainframes between each other and so now we have this kind of automated file transfer, and it just provisions account-to-account transactions between the banks.

Host:
Is there something unique about AFT that, um, is this just a sort of a standard that grew out of, um, that grew out of the ecosystem or is there something unique about AFT that’s specific to banks and other ways of transferring information, um, you know, sort of can’t be kind of facilitated?

Craig Borysowich:
Yeah, I think you would see it probably in a lot of other countries. Like in the US, it’s known as EFT. Um, so again it was just creating a networked, uh, you know, sort of more modern exchange of data between the banks in order to basically provision the account-to-account transfers.

Craig Borysowich:
Right, and then and then the idea is that, um, you know, as funds move bank-to-bank they need to settle it and that’s kind of what the, uh, automated clearing and settlement system does, the ACSS. So as they pass all these files together, the values that are exchanged are kind of tabulated over the course of the day and then that way, you know, if one bank received a whole bunch of money and then, you know, they were potentially owed, you know, actual money in order to cover the funds that are being put into accounts, right? Um, so we would subtract any funds that went back to that bank and then decide how much money needs to be settled between the two and we do that every day.

Host:
And from my understanding is this, you know, this bank-to-bank transfer, I guess the difference between this and wire transfers is the bank-to-bank transfer, uh, or I guess the AFT transfers, they are for the banks or they are for customers?

Craig Borysowich:

yeah. So it's used by the banks to facilitate account transfers between banks. Different mechanisms and services have different fees and costs. Typically, a wire transfer is used for larger values, and that’s where the Swift network plays a role, mainly with wire transfers. That’s usually why it's costly, especially with international transfers, as domestic systems aren't available for these. Swift handles international, while AFT covers domestic, smaller quantities, and higher frequencies with batch processing through the ACSS, which resolves at the end of the day.

Host:
So each day, banks determine their settlement needs to even out their books. Back in the day, someone would physically transport funds between banks for settlement.

Craig Borysowich:
Right, which is the basis for every heist movie—people robbing trains as banks moved money across the country, often in gold because it was compact and valuable. Those were simpler times when everyone was with one bank, avoiding settlements between multiple institutions. Moving money between banks now requires more oversight to ensure the banks hold what they claim for customers.

Host:
That must have been an interesting time to work in payment services. People at Payments Canada today must have unique stories, especially those with over 20 years of experience.

Craig Borysowich:
Yes, those employees have great stories about building the original rails, even before email and modern communication networks.

Host:
So we’ve discussed smaller, high-frequency transactions and larger transactions between banks and across borders. Could you explain LVTS, irrevocable wire transfers, and their significance for banks and customers?

Craig Borysowich:
Certainly. LVTS, or Large Value Transfer System, was replaced with the new Lynx platform. Lynx was initially an old mainframe application that operated for about 25 years. Now, we’ve transitioned to a more modern RTGS platform with a distributed model of virtual machines and Oracle databases. It still interfaces with Swift, and any transactions over $50,000 go through Lynx.

Host:
So, LVTS turned into Lynx, which then evolved into an RTGS?

Craig Borysowich:
Exactly. RTGS, or real-time gross settlement, is the core system managing the settlement accounting. It’s highly advanced, with business rules that make onboarding direct participants easier. Some legislative updates are underway to potentially open access to more banks. Currently, around 15 to 20 banks directly operate on platforms like Lynx and ACSS, with all others as indirect participants. There’s a minimum volume requirement for direct participation, but soon, we hope to lower that threshold, opening the system to more banks, including fintechs and paytechs, especially with the upcoming real-time payment system.

Host:
What was the incentive for maintaining large transfers through Lynx? Is it a limitation of technology or a limitation of the legislation?

Craig Borysowich:
No, I think it’s a specific difference in the way that it operates. So, in the higher-volume, lower-value transaction systems, there's a lot of things going back and forth, and then the clearing and settlement happen with a square off at the end of the day. With Lynx, it actually operates with Central Bank liquidity accounts, and that’s part of the barrier to entry to be a direct participant on the Lynx platform. You have to be a bank with a Central Bank account, and then you basically post a value of liquidity—say it's, you know, five million or ten million dollars. So, you're tying up some funds with the Central Bank to have posted liquidity. Essentially, with the large-value transactions going back and forth, money doesn’t physically move anymore between the banks. What we do is massage debt with the Central Bank on the back side of this system, and then everything is fine when we do the square off at the end of each day. That’s how they do the balancing. It’s a liquidity-backed balancing system, whereas the other systems don’t have that same liquidity capability.

Host:
So basically, it’s doing what the AFT system is doing but, because of the scale, it’s doing it at the Central Bank level. Does that make sense?

Craig Borysowich:
Yes, exactly. The AFT and ACSS platforms don’t have a liquidity backing right now. They balance things off at the end of the day, but that's within the bank. With the Lynx system, it's happening through the Central Bank. The principle is similar. The difference is that as liquidity gets out of shape, the banks have the opportunity to borrow from the Central Bank. So, the Central Bank can provide more liquidity if there’s a large imbalance of funds transacting between two banks. The bank that’s coming up short can borrow more liquidity from the Central Bank at the current interest rate, and in the settlement square-off, they’d find a way to repay the Central Bank. It ensures that funds are transferred between banks without disrupting the payment transactions themselves. It’s a more managed, Central Bank-managed method of settling between banks by having them commit funds and borrow funds from the Central Bank.

Host:
In order to use the system, you have to have an account with the Central Bank. And you're saying you’re trying to open that up to more people, and there’s legislation needed to make that happen. So, would that legislation allow other actors who have smaller sums to open accounts at the Central Bank to leverage this mechanism? Is that why it has to go through legislation?

Craig Borysowich:
Yes, and there’s also the volume commitment. There’s a minimum volume requirement to be a direct participant, and we're lowering that volume requirement. So even if a bank has a Central Bank account and liquidity sitting there, even if they're doing 100 transactions a day instead of 1,000, they can still qualify to participate on the rail as a direct participant.

Host:
Is there an incentive to open up that system? What’s the incentive for smaller actors to use it?

Craig Borysowich:
For smaller actors, they’ll benefit from direct transactions and backing from the Central Bank if liquidity is an issue. It broadens their level of access and probably reduces costs because they don't need an intermediary bank. The speed of transaction is also a big incentive. It's faster to go direct-to-direct rather than indirect-to-direct-to-another-direct and back to indirect if you’re going between two smaller banks. And, yes, there are processing fees for indirect participants going through directs.

Host:
Is this something Payments Canada wants as well? Does it make things easier on their side?

Craig Borysowich:
Actually, it becomes a bit more work for us because with more participants, we have more customers to manage directly and more relationships to maintain. We also have to work and drive consensus with the entire group of participants in order to make changes, updates, you know, things with the message sets that happen. Making, you know, changing a field from being an optional field to being a required field—we need to go out and make sure that everybody's onside with that, that systems on all sides and payments hubs and all the participants are able to do those things. So, obviously, it’s gonna make it a little bit more challenging for us. But again, it’s also about making a more efficient payments infrastructure for Canada. So, it’s sort of a balance we have to manage.

And as we get to real-time payments, we’ll see how the ecosystem changes, because, you know, there’s going to be a ceiling limit for the real-time payments. It may be a combination of payments that go over the current rails that shift to moving in real time, because if you can move money in real time, why not? So, over time, it’ll be interesting to see how some of the volumes change and how things might shift toward the real-time payments rail when it becomes available next year.

Host:
Can you talk about the real-time payments rail? You've alluded to it quite a bit, and it seems to be a big push and a big incentive for you guys. Can you talk a little about what it does and how it addresses whatever problems might exist, or just improves on things, or is simply a better technology?

Craig Borysowich:
Sure. The real-time payments rail is really designed to move money between accounts in real time. Similar to the Lynx platform, it will have a liquidity-backed solution, supported by the Central Bank. So, if we’re looking at a cap of about $7,500 to $100,000, the idea is that this is a timer-driven platform. If, for any reason, a transaction can’t complete within five to eight seconds, that payment will fail, it will be undone, and you would essentially have to retry that payment. We’d sit in the middle, monitoring, and figure out why payments might start failing.

Today, with Interac, we have services like e-transfer, and there’s no timer on e-transfers. If something flags a payment, it could take two minutes, five minutes, or up to half an hour if a bank decides they need to investigate. If they think something suspicious is going on, they’re not locked into timers. In most cases, an e-transfer will go through in a minute or two, but if you’re using an e-transfer mechanism to pay for your latte at a coffee shop, waiting for two minutes for it to clear and notify you so you can walk away with your now-cold latte isn’t ideal.

So, with real-time payments, the goal is for it to be more instantaneous, in the same way that debit is instantaneous, but more direct—bank to bank. The expectation is that, along with rule changes and other developments, fintech and paytech companies in Canada will have much easier access to use the real-time payments rail. It won’t just be locked down to the biggest banks with the highest volumes.

Host:
You mentioned e-transfers and how banks investigate concerns with the transfers for bad actors, generally speaking. With the real-time payments rail, I’m assuming this is also something you’re concerned about. So, how does that system mitigate risk, given how quick it is?

Craig Borysowich:
As it stands today with our existing rails, and this model will continue in the real-time rail, the liability generally sits with the banks themselves. But banks are limited in terms of what they see from an analytics and scoring perspective, as they operate within their four walls. They don’t necessarily have visibility into fraud activity at other banks unless it’s shared with them. There is some limited sharing of information on bad actors and problematic accounts between banks, but it’s not as robust as it could be. One of the areas we’re exploring for the real-time payments rail is incorporating support analytics in the middle of the network. This would provide a network score that banks can balance against their internal scores, complementing what banks are doing with their own systems. They'll have to make a quick decision on whether or not they're going to allow the payment based on that combination of score or not. In some cases, there's—you know, and I think, you know, the big challenge in the industry with fraud is that it does tend to be a bit of a lag, right? So, you start to notice a few things that look a little bit funny, and then you start pointing at some stuff, and then, you know, you might get in front of it in time. You can contact another institution and maybe put a hold on funds or do something before somebody, you know, initiates the next steps of basically, you know, emptying a mule account or transacting stuff out of the country. So, it's still—yeah, like, fraud in this industry is still a really big challenge, and it tends to be very responsive; it's not as, you know, probably not as proactive as people would think it is. Financial service innovations such as payment security solutions can play a role in improving fraud detection and prevention. As more people move to digital wallets and mobile payment apps, there will be an increased demand for instant payment solutions that are both secure and efficient.

But, you know, in general, it's like, "Oh, well, all of a sudden we're seeing a whole bunch of $25 transactions going to one account. This is potentially somebody, you know, fueling a scam through text messages or email," and so then people kind of have to look at it, and then they probably put a lock on the target account if they can and other things. But yeah, it's not as instantaneous and reactive as you want. And, you know, obviously, the key thing is, what we would be doing for fraud in the middle would be assisting the banks; we would not be doing anything that would stop or disrupt payment flows through our platform, right? Because, again, the liability does sit squarely with both the sending and the receiving banks.

Host: 

Well, you are helping them with that network score, which I'd love to get into a little bit. So, how does that get generated? Because, I mean, if they're relying on this, and you guys have that sort of, like, bird's eye view that they don't have, it'd be great to hear how you guys are giving them some sense of the value or security of this transaction.

Craig Borysowich: 

Yeah, and I think that's where, you know, it's a combination of providing a network scoring that goes along with their internal bank scoring and understanding reasons why our scoring might be higher or lower on a transaction. And then also that aggregate transaction view of seeing all the transactions going from multiple banks and potentially seeing a lot of particular payment flows to a specific target account.

Host: 

So, that's how that score is sort of generated, which you wouldn't see as easily within one bank, right?

Craig Borysowich: 

Exactly. It’s like, "Oh, maybe I've got four or five guys sending $25 to an account," but when we see 20 banks with 20 people each sending $25 to what could be flagged as a mule account, then we have a better ability to set a flag back to those banks to start checking into those payments and certainly the target account. We can hopefully put a hold on that target account while it's investigated before the money moves to somewhere outside the ecosystem where we can't potentially put a lock on it.

Host: 

So, from what I’m getting, the network score is basically a mix of the amount, whether it's within a consistent range, how many places it's coming from, and also where it’s going.

Craig Borysowich: 

Yes, and I’m using one specific scam model in my example, but obviously, there are a variety of different things that square and frame potential fraud. And you also have to take into account that there's a variety of other rails that could be involved. It could include credit cards, debit transactions, so there may be other transactions feeding into a real-time transaction. By combining scores from different networks and potentially correlating transactions across networks, it allows us to do time scale analytics across transactions on all the rails within Canada. This can make it easier to identify more complicated fraud activities, even human trafficking activity, because of a particular mix of transactions with specific actors on the networks.

Host: 

Alright, so multiple models—it sounds like it gets a lot more complex, right?

Craig Borysowich: 

Absolutely, we have a fraud department and a separate person that does all that stuff. I'm not the expert on broad-scale fraud, so I'm keeping it to very simple examples where I know we can have an impact.

Host: 

No, but it's informative! I think it’s good to hear how you’re taking all of those complexities into consideration and how challenging it is to manage all of it.

Craig Borysowich: 

Yeah, and the key is we're still a year or more from launching the real-time rail. Yet, we've got people on the ground working with banks and looking at this stuff because we know when it comes to bad actors in the system, they are already opening accounts, building credit scores and doing stuff specifically, you know, to prepare for the availability of this rail to basically look at how they can thwart the scoring and get at least, you know, a run of transactions going through in real time to collect money and then do the follow-on steps, right? So that's why we have people working on this. Payment security is crucial in identifying such bad actors and offering safeguards. It’s a competitive sort of mechanism, for sure, and reaction. Absolutely. And then, you know, we also have the info because other countries have already gone live with real-time payments, such as the UK, the EU, in the U.S. The Clearing House has real-time payments, plus they’re going to be launching FedNow with the Federal Reserve Bank later this year. Australia has their NTP real-time payments platform, so we're also, you know, in concert, understanding some of the challenges they're working through as well, just in general from payments and participants as well as the fraud piece and a variety of other things. This global shift in payments is being driven by advances in financial service innovations, and we can learn a lot from these international implementations. For example, digital wallets and mobile payment apps are making transactions more seamless in many regions. So we have a lot of input that we sort of have to take in and balance out how we, you know—it comes down to how we set our rules and our policies, how we manage the platform, how we add features like fraud and other things to help support and protect the rail operationally. Instant payment solutions will play a significant role as we move forward, ensuring that transactions are quick and secure.

Host

Is there a standard for international cooperation for these concerns too? Like, where, “Hey, we’ve implemented this stuff already, so here’s some information about it,” or is this just something within the industry where you take... I mean, is this kind of thing that permeates through?

Craig Borysowich

I don’t know if there’s necessarily a standard for that. I think, you know, we willingly come together—I mean, we’re kind of all in the same boat within our own countries. Bilaterally, we have conversations, and obviously, the next step, once all of us have real-time rails in the market, is how we facilitate cross-border real-time interactions between these real-time rails. So, you know, how are we going to get an RTR payment into FedNow or from FedNow into RTR? We're in those conversations as well, and we're all open to sharing and kind of helping each other because, you know, for the countries already in the market with real-time payments, they're seeing a lot of similar challenges. And so different countries have different ideas and different mechanisms for how they solve some of those problems, and sharing that stuff only makes us stronger in helping to respond to some of the issues that come up. And as we’re getting closer to being in the market with our own system, it’s been a very open dialogue with the current operators and also looking at what we might try to facilitate with cross-border transaction capabilities in the future.

Host

One question for me is, how does RTR—real-time transfer—affect the rest of the mechanisms you talked about before, like SWIFT, ACS, links? Does it become obsolete as a consequence of this solution, or...?

Craig Borysowich

Almost absolutely by definition. Obviously, you're not going to cut it off and turn it off immediately, but is the idea for it to become obsolete? And obviously, that’s going to come down to the behaviors of, you know, the people sending money, so it'll be consumers and businesses and the way they transact with each other. You know, Canada still operates a fairly heavy volume of checks. There are still people getting paid by checks instead of electronic transfers. There are a lot of business-to-business transactions that happen via check. Most of the real estate industry for buying and selling real estate is in bank drafts being exchanged between realtors and agents. So, a lot of those rails pick up pieces of that, and I think, you know, e-transfer added another mechanism, especially targeted at person-to-person transfers as well as person-to-business transfers for a lot of things.

The real-time rail will take over Interac’s e-transfer for business, so that e-transfer for a business solution that's already in play will be directly working with the RTR. So, a lot of that volume will come that way, but a lot of it’s going to be entrenched behaviors. Some of it may be changes in the way banking institutions learn to deliver services and offer services to customers to move money. Payment technologies are a driving force in these shifts, as they enhance the speed and security of transactions. So, there's a lot of opportunity, and you're right—if you say, "We'll allow transactions up to a hundred thousand dollars on the real-time rail," we know there's a good chunk of traffic going through the links platform in that fifty-thousand-to-a-hundred-thousand-dollar range that could shift into the RTR. Real-time rail is going to be domestic only, so for a lot of those international transactions, you're still going to need a SWIFT mechanism to move money out of the country and from out of the country into the country. So, that channel will continue for now. And then, as we build more connections between our real-time platform and other countries, you'll probably see a shift in the way that volumes go across different rails. This transformation of financial services is powered by the evolving landscape of payment technologies, improving how money moves across borders.

But it's still all Payments Canada volume at the end of the day, just on different rails and with different fee structures around the transactions.

Host: 

Fair enough. Speaking of fee structures, do you know if there’s an optimization for retailers in terms of fees?

Craig Borysowich: 

I'm not on the product side, so I don’t have deep knowledge on the specific fees for different rails and transfer mechanisms. So, probably not the best person to comment on that.

Host: 

Understood. Moving on, I’d love to get into the technology that makes all this possible. We’ve talked a lot about volume, and with such high volume, there’s a lot of tech involved to ensure everything works. People might be interested to know that it actually works almost 100% of the time, and I think it falls on you as the Director of Enterprise Architecture to make that as true as possible.

Craig Borysowich: 

Right. The bulk of my job is making sure we do things consistently. We have established patterns, especially for interconnectivity between banks and our rails. We've been augmenting many of our systems to offer APIs—application interfaces in a RESTful model. This is a new interface model, and adoption has been somewhat slow in the industry. Many systems are still queue-based, using MQ Series as the core mechanism for message transfer. Transitioning to APIs, even for tasks like reconciliation reports, has been gradual. But with real-time rail, we’re going to market with a fully API-driven platform, which is a significant change.

Host: 

That sounds like a big shift. I’ve read that systems like RTP in the U.S. and even FedNow are queue-based solutions. Faster Payments in the UK is a decade old, right? I believe they’re also transitioning from queue-based to API-driven solutions due to open banking mandates.

Craig Borysowich: 

Exactly. The challenge is that old banking systems handle queuing really well, and many still run on mainframe-style Big Iron infrastructure. Queuing is just easier for those platforms than building API clients in COBOL, for instance.

Host: 

So, how are you wrapping these older systems in APIs? I’m assuming there are intermediary systems enabling that transition. Also, how does your architecture handle scalability, considering the varying transaction volumes?

Craig Borysowich: 

In a queuing architecture, handling volume is relatively straightforward. Transactions just pile up, and we process them as fast as possible. In a distributed computing environment, we can spin up extra machines, whether virtual machines or containerized solutions. Spin up more and more containers to basically start chewing through that content faster. And obviously, you know, even the API model, there's a bit of queuing that goes on as well in the more modern application design and the way that we're doing delivery. With real-time payments, we have that ability to basically scale elastically based on the volume that's coming and going through the rail. This is especially relevant as financial service innovations continue to drive the need for more scalable solutions. With the rise of mobile payment apps and the increasing popularity of digital wallets, it’s essential that our systems can handle high transaction volumes securely. To ensure payment security, we must continuously improve our protocols and adapt to new threats. In addition, the demand for instant payment solutions is pushing us to refine these technologies, allowing for faster, more efficient processing in real-time.

Host

Are you managing all that server load internally? Is that something that, like, do you have people, I guess, that, you know, imagine the boxes inside and things of that nature, or are you using external services to do the scaling for you?

Craig Borysowich

Yeah, a lot of it's working through external services as we have system integrators that we work with that basically host and operate the platform themselves. We do the business, so we're interacting with the business layer of the platforms, and a lot of the technical delivery is handled through some of our service partners. But it's in the technical design, so when the products come from the vendors, they're designed to be scalable. And whether it's rapidly adding virtual machines or rapidly adding containers, and then destroying those things as volumes go down, those things are built into the operational design of the platforms that we build.

Host

Well, thanks for walking us through all that. That's quite a bit there, and I guess now I kind of want to switch over or segue from that still to a little bit of technology conversations, but more around Bitcoin and sort of how that, or I guess, cryptocurrencies, and how that affects Payments Canada's future and the future of financial transactions in general. So, could you give us, first of all, your understanding of cryptocurrency from your perspective?

Craig Borysowich

You know, when I came to Payments Canada, I had fairly wide involvement with crypto, DeFi, and some of the activities there in my prior job. So, coming to Payments Canada, I was originally working for Capco, and I was the North American lead for their Global Blockchain practice. This involved the implementation of blockchain for different use cases in the banking system, as well as understanding crypto, Central Bank Digital Currencies, DeFi, Web3, metaverse—we were working on a variety of those topics with different banks around the world in my previous role. The rise of payment technologies has had a significant impact on how these digital assets are being integrated into traditional financial systems.

I think we don't get as impacted necessarily on the cryptocurrency front. Obviously, it's still kind of in the infancy of a lot of traditional banks offering digital asset-type capabilities, whether it's cryptocurrencies or other digital assets, whether it's NFTs or other sorts of things. So, that's a rapidly up-and-coming service capability that I think a lot of banks are offering. As these payment technologies evolve, we may see more integration between traditional currency systems and newer digital assets, though at the moment, it's still largely in the experimental phase. I'm not seeing that there's going to be a lot of interfaces coming to the rails that we offer to provide a mix of traditional currency and cryptocurrency-type capabilities. We certainly don't see a lot of that on our horizon.

But I think when we switch gears to what we see with Central Bank Digital Currencies, Canada has been front and center in the conversation around using blockchain and use cases for different types of settlement models and Central Bank Digital Currencies. And different mechanisms are like projects that have been going on since probably 2016, with Project Jasper where they've been looking at examples of how some of this stuff works. A lot of that research is ongoing, and there are active projects and collaboration between the G7 and G20 countries to look at models, delivery models, and mechanisms of Central Bank Digital Currencies.

I think, from a Canada perspective, the Bank of Canada has stated that they expect a coexistence. If they do choose or reach a point, they've stated that there are three specific reasons that they would decide that they would need to launch a Central Bank Digital Currency. Although, I think as more and more countries look at launching Central Bank Digital Currencies, it'll just become one of those imperatives—everybody needs to have one. But they've basically said that they expect Central Bank Digital Currencies to live alongside the existing fiat model for quite a while. And so, that has a direct impact on us because it means that, on top of having the current capabilities of doing account-to-account transfers, we will also need to potentially be able to facilitate account-to-wallet and wallet-to-account transfers for Central Bank Digital Currencies. This opens the door for financial service innovations that could support a broader array of payment options. And that capability could be leveraged further to support cryptocurrencies and decentralized finance if that also continues to grow in popularity, and more and more services are offered in that space. As payment security becomes a larger concern, enhancing systems to secure digital transfers will be crucial. It will also involve working with digital wallets and potentially integrating them with mobile payment apps. So it'll be kind of those two things and the growth of those two things in combination and how it impacts the existing banking system and banking services that are offered in Canada. We may need to look at enhancing our systems to support that wallet functionality in the future, as the demand for instant payment solutions continues to increase.

Host: 

One thing I want to ask is, what exactly is Central Bank digital currency from the bank's point of view? How do they see that? We have Bitcoin, we have Ethereum, and we have all these technologies that act in various ways and for various reasons. So what is the Central Bank digital currency? How is that going to be used for banks, and how do they see it being used? You know, it’s not to pay for things—so what is it going to be for, right? You know what I mean?

Craig Borysowich: 

Yeah, it’s a good question. You’re right, and I’m not sure that there’s a lot of great vision of how they expect people to necessarily use it, but they’re looking at how they can augment and complement what we do with fiat currency today in a more digital model for a central bank digital currency. The key difference between a cryptocurrency and a central bank digital currency is that a central bank digital currency is centrally operated. The central bank will own all of the controls and operational parameters of that currency—how it’s issued, how it’s destroyed, how it’s used—and they have full transactional visibility of the activity with that currency. They would have much deeper reporting and understanding of different economic activities that are going on, things that are popular versus not popular in the way that people spend, and there’s a lot of great things you can do with those analytics. One of the ways to enable this at scale is by improving payment technologies that allow for seamless tracking and better integration with existing systems.

But being able to do that analytics is one of the things that kind of freaks people out. In contrast, cryptocurrency is decentralized; there really isn’t a controller. They exist and operate based on contributions from a very large number of people across many countries that make those capabilities work. It’s a very different operating model. And as we see more countries go to market—obviously, we have only a handful of countries with Central Bank digital currencies in market—I think we’ll start to see some of the possibilities and advantages, especially from a macroeconomic view of what a central bank could potentially do in influencing an economy and the economics of a country, both inside and outside of how it’s viewed internationally. As payment technologies continue to evolve, the way we manage and utilize these currencies will also change, helping improve financial transparency and stability.

So, today, we need to fight inflation, and really, the central bank has one lever, right? And it’s interest rates.

Host: 

As inflation rises...

Craig Borysowich: 

Yeah, exactly. As inflation rises, the interest rate rises because they think that’s the only mechanism they have to cool things down, even though, in the current climate and current inflationary run, there are a variety of other factors between supply chain issues and other things they’re having trouble resolving post-pandemic. It is quite possible that there could be additional levers in the way that a central bank can control the valuation of currency internationally and deal with factors relating to inflation and other economic conditions through Central Bank digital currency.

Host: 

Well, Craig, thank you very much for coming on the program. If you don’t mind, could you tell listeners where they can find you?

Craig Borysowich: 

They can find me at Payments Canada or online. I mean, if they want to go to the office, that’s one thing, but if there’s a much safer method, probably online would be great.

Host: 

Yeah, probably.

Craig Borysowich: 

The easiest way is to connect with me on LinkedIn. You can search my name on LinkedIn—I am the only Craig Borysowich there.

Host: 

Well, thank you so much for joining the program. It was great having you on. Thank you for all the information, for telling us about Central Bank digital currency, and discussing the different payment transfer mechanisms we have at different scales for various reasons. It was very informative for me, and even the research for this was interesting, so thanks so much.

Craig Borysowich: 

Excellent! Yeah, thanks for having me.

Recursive House

Recursive House provides consulting and development services tocompanies looking to integrate AI technology deeply into their companyoperations. Using our expertise we teach and build tools for companies to outcompete in marketing, sales, and operations.

Trusted Clients

Helping Clients Big and Small with
Clarity & Results

Drop us a line, coffee’s on us

What's better than a good
conversation and a cappaccino?

Address
Toronto, Ontario

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Looking for More Information?

Download our latest report on the AI market to gain valuable insights, understand emerging trends, and explore new opportunities. Stay ahead in this rapidly evolving industry with our comprehensive analysis.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
View all News

Lets Chat About Your Future

Unlock the power of AI with Recursive House’s tailored AI/ML and GenAI
services. Our expert team follows a proven development process to
deliver innovative, robust solutions that drive business transformation.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.