Cat eating pigeon related packet loss in SMS? Banking in the 21st century

So I had the honour and privilege of doing an international wire transfer today to Hungary.

After some decoding of Hungarian addresses, accents, etc., I managed to fill that in to the web interface provided by my Canadian bank (you know, the web page where the ‘wireframe’ given to the ‘designer’ was a faxed copy of a carbon-form that was designed sometime between the two great wars?).

But then it got interesting. Because we’re worried about money laundering etc., it wanted to SMS me to confirm. No problem. I don’t consider SMS secure, but this isn’t hurting me right now.

So I fill in all the fields, select the button where it tells me it will send me a TXT. A box pops up asking for the code, with A 5-min countdown timer. 5-min elapses, no codes. I search this, it turns out I need to ‘enable’ the SMS receipt by sending (you guessed it) an SMS to them first with another code. OK, done, I get an immediate response saying “You are subscribed”.

So, fill in all the fields again, same process. Hit ‘send me a code’. Nothing happens. 5-min elapses.

So I repeat. This time I get a code (Yay!), but, well, its the code from the previous run, delayed by > 5 min. Argh.

So I repeat. No code this time.

On attempt #8 the planets aligned, not only did I get a response, but it was the right one.

So the score was: 8 attempts. 2 SMS received. 75% ‘packet’ loss. And one was delayed by > 5 min.

I have a feeling that somewhere in the middle of this mess RFC 1149 was used.

For those that know telecom, SMS is not actually data. Its ‘circuit switched’, its effectively a phone call. Since I’m on LTE, which is all data, this is ’emulated’ in my carrier. So there is a translation from some protocols resembling IP to old-school-signalling. On the other end, there is an sms gateway service that the bank is using. And in between is some routing, perhaps involving pieces of paper tied to pigeon’s legs.