The long and short is that it’s part of adopting ISO20022 compliant data transactions.
The way payments Canada went about getting financial institutions compliant with the ISO, is through Interac, which provides payment services to pretty well every financial institution in the country.
What they’ve essentially done at this point, is put in a compliance requirement that everyone have the data structures and response times required for the ISO20022 data passes. So, for example, the standard may require a field for “description” with a length of 256 characters, and it may need to have something like 5 messages passed back and forth between the payer and payee systems within 10 milliseconds, to comply with the standard.
That part’s basically ‘done’ for any financial institution that uses interac payments (e transfers mostly). By ‘done’ I mean they’ve got e transfers running using the new syntax, and compliant with the requirements, of ISO20022. If it’s working for interac payments, it also generally works for other payment data exchanges too. The ISO is meant to be the ‘standard’ for all data exchanges.
The next step they’ll be doing, next year I believe, is to start populating the data fields. The standard allows for things like full receipts to be sent as part of the data exchange – in the past, you’d get just the amount, payer, payee, a brief desc, etc; now you can have the full itemized receipt and more as part of the base transaction. So step one, which is complete, ensures that systems can accommodate those full itemized receipts. The next step is to get both payer’s populating that receipt data field, and payee’s to display that data field to end users.
After that, I believe, or as part of that, they’ll also test out/enable additional features of the standard, such as allowing for limited control of account activities – ‘moving’ an account is a type of data exchange possible via the ISO syntax, but it requires closing/opening accounts between institutions, which’d required more testing.
The theory is that this will help people – basically, that by having all the extra details, they can feed it into an AI and the AI can do the fraud checks etc to clear any/all payments, allowing for things like $25k transactions to be settled in seconds (settled meaning the money’s transferred and the deal is done, no easy way to claw money back if it was wrong). It also allows for easier cross-vendor data aggregation – so you can have something like Ratehub be your online banking platform, connected up to various banks/credit unions, to show you a budgeting dashboard; or you can have a company like Wealthsimple, with it’s obfuscated deposit scheme that blurs which banks hold their deposits (they’re likely using a standard such as the iso20022 to do this).
The reality is that it’s mostly a benefit to fintechs/bigtech, with the purpose being closer to setting up a surveillance apparatus in your financial ecosystems. Having something like itemized bills in all your transaction data, for example, allows big tech to see exactly what you’re buying – this allows them better ad targeting, and potential targeting for political reasons. The standardized syntax, used for all financial transactions, makes it much simpler to pull all your financial activity in bulk – so AFTs, EFTs, Cheques, POS payments, eTransfers, wires, etc, all visible/easy to package and parse. The standard also puts control of access to that data into the end users hands – so bigtech just needs to convince a user with a flashy clickbait app to start harvesting the lot. Banks, the ones holding the data-bag/stuck with all the upgrade costs, don’t actually get access to the complete ‘financial’ picture of end users, as they don’t function as the aggregator in most cases – people will trust a third party such as ‘ratehub’ to suggest places for loans, more than someone like BMO, who would likely preference their own products; people will more likely use third party aggregators than apps made by banks/credit unions directly. Banks being bag holders, is one reason JPMorgan in the states has pushed back aggressively against this ISO, especially against the idea that aggregators get free access to bank infrastructure holding the data (aggregators have hammered infrastructure with api calls, as banks are blocked from charging for access in most jurisdictions).
There are also big outstanding risk questions. With nearly instant settlements for everything, it’s almost against end user interests. In the past, you’d have limits based on the types of transactions built into the syntax/standard of those transactions. eTransfer fraud generally had an upper limit, so the more automated settlement process had a cap on the exposure. Now the limits are essentially just a field in the transaction on the sender side, and they’re going to rely on AI/algorithms for most of the fraud checks for settlements. Being able to instantly settle $25k transactions via etransfer is cool and all, but the number of times ‘regular’ people need that is really low – enabling it as a feature, enables it for hackers to abuse. In every other jurisdiction that implemented the ISO20022, there was a significant uptick in fraud and abuse. This sort of risk is typically deemed ‘ok’ / something to sort out with AI/algorithm improvements in the future. A few extra people losing their life savings is nothing, compared to allowing companies like Wealthsimple to harvest all your data, and to kill smaller FI competitors in the market.
Very interesting, appreciate your knowledge. Thanks for the thorough explanation, I think I even followed most of it! Definitely share your concerns related to privacy/surveillance but I also look forward to the possibility for larger financial transactions to be working more smoothly on a personal level, while I agree that most regular people don’t need that too often, with inflation and the general state of the world nowadays I do find myself being aggravated by these arbitrary limitations more and more often.
Having watched Naza recently, for me, really drove home the real risks associated with data over collection by big tech / government. Seeing the very real connection between mobile phone telemetry data, and military strikes carried out during a genocide, is one of the extreme risks that can occur from such practices. I imagine similar programs/approaches are used by organisations such as ICE.
Government collects excessive information on people under the auspices of “risk management/mitigation” already. Building a system where they can see things like “Did they buy plan B?” feels like a really bad idea, unless there’s a really, really fucking good reason for the government and big tech to know that information. And by really good reason, I’d say it’d need to be demonstrably saving lives somehow, given the potential negatives.
The long and short is that it’s part of adopting ISO20022 compliant data transactions.
The way payments Canada went about getting financial institutions compliant with the ISO, is through Interac, which provides payment services to pretty well every financial institution in the country.
What they’ve essentially done at this point, is put in a compliance requirement that everyone have the data structures and response times required for the ISO20022 data passes. So, for example, the standard may require a field for “description” with a length of 256 characters, and it may need to have something like 5 messages passed back and forth between the payer and payee systems within 10 milliseconds, to comply with the standard.
That part’s basically ‘done’ for any financial institution that uses interac payments (e transfers mostly). By ‘done’ I mean they’ve got e transfers running using the new syntax, and compliant with the requirements, of ISO20022. If it’s working for interac payments, it also generally works for other payment data exchanges too. The ISO is meant to be the ‘standard’ for all data exchanges.
The next step they’ll be doing, next year I believe, is to start populating the data fields. The standard allows for things like full receipts to be sent as part of the data exchange – in the past, you’d get just the amount, payer, payee, a brief desc, etc; now you can have the full itemized receipt and more as part of the base transaction. So step one, which is complete, ensures that systems can accommodate those full itemized receipts. The next step is to get both payer’s populating that receipt data field, and payee’s to display that data field to end users.
After that, I believe, or as part of that, they’ll also test out/enable additional features of the standard, such as allowing for limited control of account activities – ‘moving’ an account is a type of data exchange possible via the ISO syntax, but it requires closing/opening accounts between institutions, which’d required more testing.
The theory is that this will help people – basically, that by having all the extra details, they can feed it into an AI and the AI can do the fraud checks etc to clear any/all payments, allowing for things like $25k transactions to be settled in seconds (settled meaning the money’s transferred and the deal is done, no easy way to claw money back if it was wrong). It also allows for easier cross-vendor data aggregation – so you can have something like Ratehub be your online banking platform, connected up to various banks/credit unions, to show you a budgeting dashboard; or you can have a company like Wealthsimple, with it’s obfuscated deposit scheme that blurs which banks hold their deposits (they’re likely using a standard such as the iso20022 to do this).
The reality is that it’s mostly a benefit to fintechs/bigtech, with the purpose being closer to setting up a surveillance apparatus in your financial ecosystems. Having something like itemized bills in all your transaction data, for example, allows big tech to see exactly what you’re buying – this allows them better ad targeting, and potential targeting for political reasons. The standardized syntax, used for all financial transactions, makes it much simpler to pull all your financial activity in bulk – so AFTs, EFTs, Cheques, POS payments, eTransfers, wires, etc, all visible/easy to package and parse. The standard also puts control of access to that data into the end users hands – so bigtech just needs to convince a user with a flashy clickbait app to start harvesting the lot. Banks, the ones holding the data-bag/stuck with all the upgrade costs, don’t actually get access to the complete ‘financial’ picture of end users, as they don’t function as the aggregator in most cases – people will trust a third party such as ‘ratehub’ to suggest places for loans, more than someone like BMO, who would likely preference their own products; people will more likely use third party aggregators than apps made by banks/credit unions directly. Banks being bag holders, is one reason JPMorgan in the states has pushed back aggressively against this ISO, especially against the idea that aggregators get free access to bank infrastructure holding the data (aggregators have hammered infrastructure with api calls, as banks are blocked from charging for access in most jurisdictions).
There are also big outstanding risk questions. With nearly instant settlements for everything, it’s almost against end user interests. In the past, you’d have limits based on the types of transactions built into the syntax/standard of those transactions. eTransfer fraud generally had an upper limit, so the more automated settlement process had a cap on the exposure. Now the limits are essentially just a field in the transaction on the sender side, and they’re going to rely on AI/algorithms for most of the fraud checks for settlements. Being able to instantly settle $25k transactions via etransfer is cool and all, but the number of times ‘regular’ people need that is really low – enabling it as a feature, enables it for hackers to abuse. In every other jurisdiction that implemented the ISO20022, there was a significant uptick in fraud and abuse. This sort of risk is typically deemed ‘ok’ / something to sort out with AI/algorithm improvements in the future. A few extra people losing their life savings is nothing, compared to allowing companies like Wealthsimple to harvest all your data, and to kill smaller FI competitors in the market.
Very interesting, appreciate your knowledge. Thanks for the thorough explanation, I think I even followed most of it! Definitely share your concerns related to privacy/surveillance but I also look forward to the possibility for larger financial transactions to be working more smoothly on a personal level, while I agree that most regular people don’t need that too often, with inflation and the general state of the world nowadays I do find myself being aggravated by these arbitrary limitations more and more often.
Having watched Naza recently, for me, really drove home the real risks associated with data over collection by big tech / government. Seeing the very real connection between mobile phone telemetry data, and military strikes carried out during a genocide, is one of the extreme risks that can occur from such practices. I imagine similar programs/approaches are used by organisations such as ICE.
Government collects excessive information on people under the auspices of “risk management/mitigation” already. Building a system where they can see things like “Did they buy plan B?” feels like a really bad idea, unless there’s a really, really fucking good reason for the government and big tech to know that information. And by really good reason, I’d say it’d need to be demonstrably saving lives somehow, given the potential negatives.