FAQ — Can scalpers bypass the system by buying tickets on throw away simcards and selling these?
Question: As GUTS Tickets currently uses a SMS verification in order to login to a smart ticket doesn’t this mean that scalpers could sell trow-away smart phones(or sim-cards) with smart tickets on them and resell those? Wouldn’t that completely way of reselling circumvent the margin control protocol as described in the protocol?
Answer: As of now, yes it would, selling physical phones will completely circumvent the SMS verification and thus allow for unbounded margins on the tickets sold. However, this would mean that scalpers would have to set up infrastructure to sell and ship a physical object(a SIM-card or a sell a whole smart phone) holding the smart ticket.
Currently all a re-seller of a ticket has to do is email a PDF file containing a QR code to the buyer. It doesn’t require much analysis to conclude that emailing a static QR code, as is now common with current ticketing infrastructure(mostly based on having a unique email address), is a lot cheaper, more scale-able and thus more profitable for scalpers.
In addition the tickets distributed by our smart ticketing system are dynamic and can contain multiple tickets in the same (changing) QR code. This means that scalpers cannot split up tickets as easily as they could when they bought tickets with static QR codes as this where just PDF files.
Benefits of SMS verification
The SMS verification method makes reselling of scalped tickets with bots a much bigger hassle as scalpers would have to start shipping/swapping physical phones and/or sim-cards. Basically it will take the scale out of online ticket scalping and even if scalpers can make it scale it will drastically increase operation costs for scalpers as hardware investments and infrastructure will be needed. Higher costs for the scalper will mean higher mark-ups for the buyers of the ticket. Besides to guarantee higher costs for scalpers/buys it will also result in that when buying a secondary ticket the buyer will have to take into account the shipping time for the phone/SIM card to arrive at their address. This making last-minute reselling/trading practically impossible. Using such a ticket is also much less easy(as you’ll have to either swap SIM cards or boot up your new throw away smartphone). Overall this verification method goes a long way, just not all the way.
Balancing solving the problems and ticketing user experience
When solving the ticket scalping problem one seeds to find a delicate balance between preventing large scale ticket scalping while at the same time ensuring that buying a ticket won’t become an endless process of entering data and verifying endpoints. One should recognize that a perfect and ‘watertight’ solution (like putting tickets on name, like with a plane ticket) and thus requiring people to identify themselves at the entrance of a venue is not the solution. It only moves the burden of proof to the entrance of the venue, which isn’t exactly ideal from an venue/organizer & crowd safety perspective. You don’t have to take my word for it, there are numerous events that have tried this ‘plane-ticket’ approach. Check news articles about these attempts here
(1,2,3). Overall this approach doesn’t really seem to work.
Also I am personally of the belief that identifying yourself with an ID card is kind of medievalish, why not use the thing that we literally use for everything else in our lives? Why not bring event ticketing to the 21st century and use the smartphone like we use for messaging, news and even payments. Why not ticketing then?
Usable ≠ scale-able ≠ executable ≠ sell-able
Be aware that SMS verification is a type of identification/uniqueness-assessment
that is well known by your everyday consumer/attendee. This ease of use factor is crucial for the sales proposition of GUTS/GET towards their target customer. Organizers won’t adopt a ticketing solution if it requires their consumers to be all tech-savy or lets them jump through countless verification hoops.
It is important to acknowledge that an event organizers first concern is
ensuring an event sells out, the scalping concern is ‘merely’ secondary. When given the choice an organizer will prefer a sold out show to a highly scalped/resold not sold out show. Organizers generally stop caring about outrageous secondary ticketing prices as soon as solutions to this problem start cutting into their margins.
More tricks up our sleeve
Ticket scalping is an problem that has been around for quite some time. As such we are far from the first that are trying to tackle it. Centralized ticketing companies have been trying to hamper scalpers for decades. For example detecting the use of the similar/flagged credit/debit card numbers for example to check the uniqueness of the individual buying the ticket. There is a wide array of comparable of tools at the disposal of the ticket seller to determine uniqueness and ‘genuine intention’ of a buyer. As we propose a hybrid solution we also can deploy these tools, making them more effective with the help of AI/Machine learning on the scalper profiles and behaviors we collect as we go. That being said, at the end of the day all these measures are (and historically have been) an arms-race in verification by the tickers. In the case of detecting similar payment identifiers (a uniqueness technique first introduced by Ticketmaster in the 90’s) it became common practice for scalpers to collect creditcard numbers from consumers before a ticket sale began.
The point is, that you will be always be one step behind that of the scalpers as they are found out one more trick to beat the system. That is why we are so focussing on the smart-phone locked ticket as this at least has the limitations of it being a physical asset being provisioned.
Addition of other identification methods to the protocol
Having acknowledged that SMS verification isn’t perfect it should be noted that SMS verification is just the first identification method that is deployed/operational/used. More identification methods will be added in the future(a general outline of which will be given in the next sections). These extra verification methods will allow the protocol to make an even better assessment if a buyer is a individual that actually wants to attend an event or is likely to resell the ticket. More identification methods means more data the protocol is able to add/process and attribute to a certain user/attendee profile. This data will form the shared data layer for fans and event attendees on which the protocol will be able to make decisions/assessments. Read more about the concept of a shared data layer in this blog post by Joel MN.
Shared data layer
This enriched user data profile could be used as a way to determine or predict a users intention when buying a ticket for a certain event. How this prediction is used is up to the event organizer / venue / artist or ticketing company to decide, after all the GET Protocol should be seen as a ‘fat protocol’ on which ticketing applications are run. In the end it is up to the ticketing applications built on top of the protocol to decide what the rules are of the ticket sale of a certain event. The protocol just provides organizers with the tools and data standardization to make their ticketing honest and transparent. How the variables of the protocol are set up per event-cycle it not up to the protocol, but to its the artist/organizer.
Fat protocols & thin applications
Here’s one way to think about the differences between the Internet and the Blockchain. The previous generation of shared protocols (TCP/IP, HTTP, SMTP, etc.) produced immeasurable amounts of value, but most of it got captured and re-aggregated on top at the applications layer, largely in the form of data (think Google, Facebook and so on). The Internet stack, in terms of how value is distributed, is composed of “thin” protocols and “fat” applications. As the market developed, we learned that investing in applications produced high returns whereas investing directly in protocol technologies generally produced low returns.
This relationship between protocols and applications is reversed in the blockchain application stack. Value concentrates at the shared protocol layer and only a fraction of that value is distributed along at the applications layer. It’s a stack with “fat” protocols and “thin” applications.
We see this very clearly in the two dominant blockchain networks, Bitcoin and Ethereum. The Bitcoin network has a $180B market cap yet the largest companies built on top are worth a few hundred million at best, and most are probably overvalued by “business fundamentals” standards. Similarly, Ethereum has a $92B market cap even before the emergence of a real breakout application on top and only a year after its public release.
There are two things about most blockchain-based protocols that cause this to happen: the first is the shared data layer, and the second is the introduction cryptographic “access” token with some speculative value.
What’s significant about this dynamic is the effect it has on how value is distributed along the stack: the market cap of the protocol always grows faster than the combined value of the applications built on top, since the success of the application layer drives further speculation at the protocol layer. And again, increasing value at the protocol layer attracts and incentivises competition at the application layer. Together with a shared data layer, which dramatically lowers the barriers to entry, the end result is a vibrant and competitive ecosystem of applications and the bulk value distributed to a widespread pool of shareholders. This is how tokenized protocols become “fat” and its applications “thin”.
-The full blog about the difference between fat and thin protocols can be found in the blog post on the subject found here.
More about fat protocols and thin applications
The GET Protocol can be seen as a ‘fat protocol’ meaning that the applications working on top of it (like the GUTS Tickets smart ticketing application) can make their own choices on how they handle the functionalities offered by the protocol. Event organizers/artists can make their own choice in if they allow ‘un-reputable phone numbers/user-profiles’ (or foreign phone numbers for example) to acquire tickets for their event. Event organizers could also choose to restrict certain bank/credit-card accounts that in the past have been associated with scalping. If organizers think that the scalping risk is high for a specific event they could choose to restrict sales only to buyers acquiring the smart ticket via the native GET/GUTS application on their smartphone. A native application adds a wide array of possibilities to a users profile as it can use hardware/software integrations like GPS, fingerprints, NFC, Bluetooth and software payment applications already installed on the phone.
Scalper data-profile, reputation and dynamic pricing
Besides using SMS verification a buyer of a ticket has to provide/provides other data-points when acquiring a ticket. SMS verification is only the first implementation of GUTS / the GET Protocol to access/control for the uniqueness of a buyer. There are other ‘login’ options GUTS/GET is planning to roll out in the near future. Note that these options are not exclusive, one could imagine a user profile that has multiple login/verification options. Each verification option adding more trust to the users profile.
Additional identification options are for example:
- Biometric identification (fingerprint).
- Using blockchain identification/reputation protocols like CIVIC to ensure a certain individual is unique/trustworthy.
- Usage of social-logins(Facebook, Twitter etc.) applications to add to your user profile on the GET protocol.
- Integration into festival applications or other existing software/platforms that have user/fan data.
All aforementioned login methods should not be seen ‘in isolation’ — meaning that identification methods can be used in combination with each other.
The organizer decides
In the end it is up to the company/artists using the GET protocol to decide which login methods and scalpers assessments are deployed/used. The protocol merely provides the tools, how the tools are used is up to the organizer yielding them. In the end we are of the belief that due to its transparent nature, the blockchain will ensure that whatever choices are made by the organizer, they cannot hide.
Identity management
First of all it should be clear that the reason why we use SMS verification to access/lock the smart ticket on a buyers phone is because we want to ensure no one entity/company is able to buy up large amounts of tickets for resell purposes. As mentioned before this SMS method isn’t perfect/complete but it does make reselling of tickets with a profit intent a **much ** bigger hassle than before.
In future blogs/publications we’ll elaborate our stance on data collection, re-marketing and data ownership.
More about the GET Protocol
You can acquire your GET here.
Any questions or want to know more about what we do?
Join our active Telegram community for any questions you might have,
read [our whitepaper](https://guts.tickets/files/GET-Whitepaper-GUTS Tickets-latest.pdf), visit the website, or get yourself a smart event ticket in our sandbox environment.