That's impossible now as all payments just use the IBAN and the sort code is built into the IBAN. I'm fairly sure it goes Country Code-CheckDigits-BIC-OldSortCode-AccountNumber.The only time I have encountered a problem and maybe that no longer exists now that UB is gone as maybe the system was specific to them was when I sent money to the right account number and wrong sort code. I had accounts in two different UB branches so had two sort codes and I quoted the wrong account number with the non matching branch sort code. It went through to someone else's account. Turned out UB reused their account numbers across branches so if you got a sort code wrong as in a correct sort code but for the wrong branch then there was a risk it would hit a valid account combination but not necessarily yours!
There were 7 branches in the country that had that particular account number so getting the right sort code was vital! Those new checks should catch that though as name would be different.
Perhaps OT but I wonder how this will play out in practice, particularly for businesses.The destination bank will send a response (e.g. match, no match, close match, check not possible).
Sounds like it'll be impossible to send a transfer to an Irish bankThere is a 5 second window for this (end to end) so it should offer some comfort in realtime when setting up a payment transfer.
This can't happen any more since sort codes have been done away with.The only time I have encountered a problem and maybe that no longer exists now that UB is gone as maybe the system was specific to them was when I sent money to the right account number and wrong sort code. I had accounts in two different UB branches so had two sort codes and I quoted the wrong account number with the non matching branch sort code. It went through to someone else's account. Turned out UB reused their account numbers across branches so if you got a sort code wrong as in a correct sort code but for the wrong branch then there was a risk it would hit a valid account combination but not necessarily yours!
There were 7 branches in the country that had that particular account number so getting the right sort code was vital! Those new checks should catch that though as name would be different.
Isn't this really up to the customers?Perhaps OT but I wonder how this will play out in practice, particularly for businesses.
A lot of businesses accounts don’t use their trading name or use the name of the proprietor. Not to mention many married women still have an account in maiden name.
A lot of payers could end up making false rejections of legitimate transfers as they will get a warning that the payee name doesn’t match what they’ve entered.
I hope there’s some kind of effort to clean this up in advance of account verification.
I agree. I know of one firm with a well-known trading name collecting thousands of direct debits monthly with the proprietor’s full name appearing on all of the transactions. It’s daft.If you're carrying on a business under one name, but operating it using a bank account in another name, maybe stop doing that?
Sure. But the people primarily disadvantaged by this are not the payors; they're the payees. They're the ones who lose out if payments are held up, diverted or not made at all.But there are systemic issues here about trust in the SEPA payments system that are bigger than individual businesses. Naive people (of which there are many) could be turned off EFT as a means of payment if they frequently get these messages warning them of a non-match.
Are they no longer part of the IBAN? Has the format of it changed or is changing.This can't happen any more since sort codes have been done away with.
Of course. The issue will self regulate to some extent. But there is a broader issue about ease of use of the SEPA infrastructure.But the people primarily disadvantaged by this are not the payors; they're the payees. They're the ones who lose out if payments are held up, diverted or not made at all.
There is no longer a system of directing payments using sort codes. The IBAN is a unique identifier for each bank account. Banks that previously used sort codes have incorporated those codes onto their IBANs, but standalone sort codes are no longer a thing.Are they no longer part of the IBAN? Has the format of it changed or is changing.
There is a kind of checksum that invalidates most simple data entry errors automatically.IE35AIBK 931063 13245768
This......?There is a kind of checksum that invalidates most simple data entry errors automatically.
2. IBAN Check Digit
Integrity check on the IBAN using ISO 7604 (MOD 97-10) algorithm is performed at this step.
It will be very interesting to see how it plays out. Apparently it applies to batch transactions as well as online/interactive. So think of a large accounts payable batch of payments being submitted (with all the wrong names as has been pointed out here). Or the first time a large Paypath payroll batch is submitted. Ireland is particularly vulnerable, given the cavalier attitude the banks have had into name checking on cheques and allowing virtually any name on a cheque to be lodged, even when crossed. The British banks were always far tighter on this. To add to the concerns, Verification of Payee is being implemented on a very short/tight timeline. The rulebook was only published in October 2024. So it could be a bumpy ride. But is definitely necessary given the huge volume of online/interactive/realtime transactions, especially with the onset of SEPA Instant which is a game changer. But also worth considering that SEPA has been well managed and quite successfully rolled out so far.Perhaps OT but I wonder how this will play out in practice, particularly for businesses.
In your example, the "35" is the checksum. This is calculated by running all the other numbers and letters (A=10, b=11, C=12, X= 33, Y=34, Z=35) through a routine. If you change any one number or letter in the IBAN the result is guaranteed to be different and checksum will be invalid, and so your second IBAN is guaranteed to be rejected. There is a possibility if there are multiple errors (two or more substitutions or transpositions) that the result of the calculation will be the same, but it is very remote possibility, far too remote to be bothered about.Is it not possible to make a mistake in the IBAN and accidentally put in a valid number?
So if the number is
IE35AIBK 931063 12345678
And I put in
IE35AIBK 931063 13245768 Could that not be a valid number?
Or is it that what is effectively a 14 digit account number, if I make a mistake, the chances of it being a valid number are vanishingly small?
It could still occur if you continue to calculate/guesstimate IBANs. Which is a good reason not to do so, and request the actual IBAN from the payee instead of using an IBAN calculator to calculate it, potentially with the wrong data.I would have thought my error could still occur, now mind you small risk and it would be customer error as if I was quoting the IBAN and I put in what used to be the sort code which is incorporated in the IBAN now cos there are several of them in my head memorised then if the UB system was still in place I could hit a valid account in another branch, no?
As in example above when I read IBANs in my head I split the 93-10-63 as I remember them when they were sort codes so what if I put in 93-62-19 with my correct account number is there a chance that will hit a valid account in AIB Tralee or is there only one usage of an account number anywhere in the country?
if you continue to calculate/guesstimate IBANs.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?