SMS Sender ID registries have become a popular approach to tackle SMS fraud, particularly across Europe, and like many good ideas in telecoms, they tend to look very straightforward on paper.
Those of us working in the fraud and security messaging world build and sell these kinds of solutions, but so global is our work, we don’t often interact with them. This is a story describing what happened next when I became an end user of one.
Ireland’s SMS Sender ID Registry
Ireland’s Communications Regulator, ComReg, has introduced a mandatory SMS Sender ID registry. The premise of this registry is quite straightforward; those who wish to send A2P messages terminating in to Ireland must register that specific Sender ID with ComReg through an online portal, along with proof they have the right to use it.
Timelines:
- 3 July 2025: after this date, any message from an unregistered Sender ID would be modified to show “Likely Scam”.
- 3 October 2025: initially, the blocking of Application-to-Person (A2P) SMS messages from unregistered Sender IDs were scheduled to commence from this date, however ComReg later paused any blocking.
- 16 April 2026: ComReg released their latest report on nuisance communications, showing the number of registered SMS Sender IDs is 20,252 and the number of Sender ID owners is 14,931.
Why I’m Even Writing about This
The SMS Sender ID solution sounds entirely reasonable, and it is. Effective fraud prevention and detection mechanisms are rarely simple approaches, and instead are often performed by lots of small controls layered together, one a time, and usually done in tiny steps to purposefully make it just a bit harder for a fraudster to continue, effectively making it more enticing for fraudsters just to go somewhere else. A Sender ID registry is absolutely one of those controls that work to reduce SMS fraud, and it will and shall help reduce the tremendous amount of spam terminating into Ireland.
So far, so good.
My perspective: I’ve worked in telecom fraud detection solutions for over 10 years across three different vendors (currently working for AB Handshake) and also from the operator’s side. I’ve essentially been on both sides of these systems; an end user, helped build them, fixed them when they break, created new functionality in response to new frauds, and have worked with building AI fraud detection approaches for so long before it was cool that I still call it ML.
I also have enough pride in Ireland that I really wanted this to be done so well it could lead the way in SMS fraud prevention approaches as more countries follow, and if I’m honest, I also just wanted the Irish solution to be the best. I am also a strong fan of collaboration in the world of fraud detection, and opening your solution up to criticism is one of the most effective ways to improve it and uncover blind spots you didn’t know existed.
What Could Possibly Go Wrong? A Sailing Club Meets the Sender ID Registry
If you want to see how people work with this Sender ID Registry in the real world, you have to start in an unlikely place — a sailing club in Dublin known as “Clontarf Yacht and Boat Club”. The average age in my sailing club is comfortably pushing retirement. These people love, eat, and sleep sailing. The club itself is so old that the grandson of Arthur Guinness — the inventor of Ireland’s best-known beverage — was our first President. It retains strong links to the Guinness family.
Our club also has a Sender ID we use for quite important communication: the opening times for our club’s bar. We’re a tidal sailing club, which means we only sail at high tide, and the bar opens at times that follow sailing times, which means the opening times frequently change (for those wondering why you would even need to send SMS’s so frequently).
The sailors in this club, although many are retired, are quite frankly intimidatingly capable people. If you can survive alone out on the Atlantic, by golly you are able to register a Sender ID to send SMS’s, and between them, we have just about every profession in Ireland: doctors, aeronautical engineers, CFOs… all the way to myself, a Product Manager in AB Handshake. Our sailing club’s members do however share one common blind spot: their limited interest in topics that aren’t directly sailing related (eg: SMS Sender ID Registries).
Letting It Break (on Purpose)
When the SMS registry was introduced in Ireland, I knew I could handle it for the club without much effort, but I deliberately stepped back. I was more interested in seeing how it would unfold in other groups out there that didn’t have someone like myself present.
After the July registration deadline passed without our club registering our Sender ID, our SMS messages started being labelled as “Likely Scam”. I let this run for a few weeks, hearing everything from “we’ve been hacked” to “the club is sending viruses now, don’t open those messages”. Seeing that there was no one else coming to fix this, I approached our Commodore (super fancy sailing speak for ‘current club president’) who was, let’s say, relieved when I told him I could fix it. He told me he had been trying to contact the software company we pay for managing our SMS’s to figure out next steps, and they simply hadn’t replied, which it turns out becomes quite a theme in this story.
Registering the Sender ID (Where the Fun Began)
Registering our Sender ID should have been straightforward. It was not.
After 20-something minutes of trying to load the website on my phone to register our Sender ID, I realised the portal only worked on a laptop. The irony of an SMS-based mobile communication system that can’t be set up on a mobile phone was not lost on me.
On a laptop, things didn’t improve much. It was genuinely hard to tell whether this was an intentional fraud prevention measure (the classic approach of making it just awkward and hard enough to annoy fraudsters so they give up, something often used in many subscriptions fraud controls) or simply buggy software.
ComReg (or the vendor behind) did speedily respond to these problems and have since updated the wording and added an FAQ. Which strongly suggests I wasn’t the only one stuck at this point.
The OPA Problem
Then came our actual issue. I was asked to select our “OPA”, a term seemingly created for this registration.
OPA’s are defined by ComReg as:
Your Originating Participating Aggregator (OPA) is your SMS Service Provider that is responsible for transmitting your SMS messages. You will need to know who your OPA is to properly register your SMS Sender ID. If you do not know who your OPA is, there may be a Third Party organisation that can provide this information. This would typically be a software vendor that you acquired a solution from to send SMS messages to your customers. If there is a Third Party involved, you also need to add them from a drop-down list and also add your OPA(s) from another drop-down list.
On ComReg’s site there is a list of (at the time of registration) 95 different OPA’s in Ireland. I had no idea which one we were using, neither did our Commodore, and we had no way of finding out. He contacted our SMS provider yet again to ask (no response again, 3 months so far).
At that point, there wasn’t really any “correct” option, just a choice between choosing the wrong OPA (with 95 options to choose from), or not registering at all. I came up with a creative solution: as I couldn’t identify the correct OPA, I selected all 95.
I would like to emphasize this multiplied the workload by 95 for the poor person in ComReg who had to approve our Sender ID on all 95 routes. Most importantly however, it effectively enabled our Sender ID to be used across the entire SMS ecosystem, and by doing that, enabled fraudulent messages to be sent using our Sender ID from anywhere, to anyone in Ireland, via any route. In trying to comply with the system, I had just bypassed part of what it was trying to enforce and essentially opted us ‘out’ of fraud management.
I am also sure I’m not the only person who solved this problem this way, as ComReg later updated their guidance to say “up to five OPAs is normal,” which tells its own story.
I explained my “creative solution” to the Commodore and told him to let me know when ComReg inevitably contacted him saying we can’t do this, which they did. He received a warning telling him he must choose the actual OPA or risk follow up action, while they temporarily allowed us to proceed with our Sender ID.
What Actually Happened Next
For a while, our messages continued to send as normal with our (temporarily) approved Sender ID.
As of April 2026, our SMS’s have returned to being marked as “Likely Scam”, which is why I’m freely able to write about this now, as sharing our Sender ID is no longer a risk.
The most sombre and likely final update to this story: last month, our club created a WhatsApp Community. There are 20 WhatsApp groups comprised within it, with one group entirely dedicated to the bar. Our WhatApp community is thriving.
Larger Impacts
I started wondering more about how other groups were solving problems like this, and how SMS fraud was actually responding. My approach to data gathering for trustable information about fraud patterns is usually very… manual. I ask for volunteers across my day-to-day life to show me their messages, and in many ways, I find these the best examples as they’re randomized, and give an unbiased view of what’s actually happening across Ireland.
What I have found:
- SMS fraud didn’t stop, it just moved, almost impressively fast. It has migrated to P2P routes, and instead of spam messages being labelled “Likely Scam,” they now usually originating from P2P Irish MSISDNs, which arguably make them more convincing.
- Notably, my own Irish operator is currently sending me voicemail notification messages from what looks like a P2P SIM Box instead of registering, which tells its own story.
- Ireland supports numeric-only short codes which are separate to this Sender ID system. SMS Fraud is now originating through these numeric short codes, something I personally have not encountered before.
- Many legitimate businesses still haven’t registered to date, so their SMS’s continue to be flagged as “Likely Scam”. Ironically, this means if you receive a message from a “Likely Scam” Sender ID, it’s now actually almost guaranteed legitimate as fraudsters have effectively abandoned the A2P channel entirely.
- Some businesses seem to have taken a different route possibly due to registration complexity, or maybe because this forced them to rethink their SMS setup, and they appear to have moved messaging onto P2P routes instead, further shifting traffic away from A2P.
- One interesting case from April 2026: I personally received an P2P SMS labelled “Likely Scam” from a friend outside Ireland, sent from an iPhone. This may point to a broader issue affecting incoming P2P traffic on international links, or alternatively indicate a much more serious misconfiguration introduced alongside changes related to the Sender ID registry on my home network.
My Sailing Club’s Sender ID Issues Are Not Critical; Others May Be
One example edge case I see in the data is Ireland’s Blood Donation Clinics. What I see from my data is they currently send clinic reminder SMS’s via Irish P2P routes. It’s important to highlight here that this may be intentional, pre-arranged with Irish operators, already protected, or even these P2P MSISDN’s may be registered numeric Sender IDs, but it does highlight a very real risk: if an SMS cannot afford to be blocked or even labelled as ‘Likely Scam’ then the safest option may be to avoid the regulated channel entirely, and that’s something worth highlighting.
As I see SMS spam, fraud and scams continually rise on the national P2P route, the next phase of SMS fraud management in Ireland will likely move when permitted to fraud management of the P2P channel. There is a necessity for extreme care here, with blood donation services being the perfect example of a group sending SMS’s that simply cannot afford to be mis-labelled for a day, never mind blocked, and who might not figure out a way to report it if they are. Keeping in mind, my sailing club still hasn’t gotten a reply from our SMS software company vendor almost 1 year later.
Where (I Think) This Goes Next
Ireland’s system has laid a good path, and they will continue to evolve this system.
- ComReg ideally will address the OPA problem further, because right now end users simply may not be able to identify their OPAs. Perhaps mandating registration from software companies rather than end users is key. I hope this article pushes ComReg in this direction as I’m sure my sailing club is not the only group affected by the OPA issue.
- ComReg will likely extend protection to numeric Sender IDs as that gap is already being exploited.
- P2P Route Fraud Protection: where appropriate and permitted, there are solutions that can provide this including from AB Handshake.
(My) Comments for the Next Country that Follows Ireland
- Test any approach with real people, not telecom professionals. If your friendly neighbourhood sailing club can’t complete the process by themselves, something is wrong.
- If you’re open to collaborative feedback, ask people in the industry to break your system, especially those who care enough to go to the effort of registering an SMS Sender ID across 95 OPA’s.
- Make sure your vendor makes the registration page accessible on a phone browser; it’s SMS.
- Keep edge cases in mind. Not everything fits neatly into A2P and P2P, and some cases are critically important like blood donation centres who simply cannot risk having their SMS’s blocked or marked as “Likely Scam” for any amount of time. But please also keep in mind small sailing clubs who just want to know when they can get a pint of Guinness next week.
- The dream scenario: where possible and permitted, you should of course deploy protections across all routes in a country simultaneously, including P2P. Otherwise, traffic (both legitimate and fraudulent) will simply move to wherever the friction isn’t. Fraud never stops, it only changes.
Final Thoughts
I’ve spoken a few times about this topic at the GSMA’s Fraud and Security Group events, most recently in Malaga in February 2026, and prior to that in Tunisia in November 2025. The takeaway: during my last presentation, just weeks before Mobile World Congress 2026, a virtual attendee from Ireland commented he had just registered online and received a GSMA confirmation SMS marked “Likely Scam”. If you’re looking for where to start improving SMS systems like this: let’s start there.
