A Smart Solve for Risk Management
For any ISV in the event/ticketing management verticals, payment is inherently risky due to fraud losses or managing cash for refunds when reservations cancel. Those verticals span live music, sporting events, hotels, airlines, or large special events in attractions.
No off-the-shelf payment solution exists to manage such risk so that the ISV can own payments profitably since, in payments, whoever can manage the risk reaps the financial rewards of doing so. Instead, today, regrettably, the risk is passed on to the client of the ISV, a seller who then needs to deal with the un-enviable complexity of high processing costs from card processors, merchant banks, and often insurance companies with all kinds of agents in between to spread the risk out between parties. As you can imagine, this is an inefficient way to price due to manual labor and incomplete access to data to understand all payment, event, and traveler/visitor attendance dynamics.
Let us stress that the patterns of fraud or refunds in event/ticketing differ from online retail, which is relatively well solved by now, given it was the most prominent early market as the web expanded. The differences are really in the stealing of digital goods, most often a QR code for resale, or being able to have cash on deck to refund when significant events cancel.
At ACME Payments, we have learned how to solve those types of fraud, or refund needs, via almost a decade of owning payments in the ticketing/event verticals. Our evolution has gone from manual to hybrid automation to mapping out our AI-based roadmap for full automation.
The enabling attributes to managing such risk are based on two main qualities of our payment tech stack:
First, we board every seller onto our rails as a sub-merchant to our merchant account since we are a regulated Payfac. From the standpoint of managing the refund risk, this aggregation construct lets us diversify this risk into layers, each layer bearing a component of the risk depending on the aptitude to provide cash reserves or price it up the chain, much like insurance companies operate, for instance, or even banks.
Additionally, the aggregation construct provides other economies of scale in straight card processing costs. It reduces the complexity of the ISV client, also a seller, by only signing up for the ISV application, which provides payment services. No more need to sign up merchant banks, card processors, and insurance companies for the ISV client. Certainly a much more appealing ISV from the seller‘s perspective.
Secondly, and this is the AI applicability, our system of record tightly integrates payments to events being sold and visits happening via scanning flows. We can correlate risks by requesting the necessary data for our AI-based algorithms during the boarding and payment acceptance API calls. Given that we control the seller’s funding, we can more precisely adjust the funds to refund risk, for example, to keep enough funds for the probability of event cancellation.
From such a vast integrated payment and event database, which essentially is a network given we are the system of record for all of our sellers, we can now run sophisticated machine learning systems to understand risks automatically with complete information access.
For payment acceptance, as an example, we can score IPs against card declines or past transactions flagged after the sale to be refunded automatically before they turn into chargebacks. Such scored IPs, or proxy by interpolation, are then either blocked or presented with challenges to make checkout even harder to help reduce fraud on our network.
As mentioned above, a considerable risk area is managing refund risk on the probability of event cancellations. We can correlate the future rate of refund risk to locally based information on our network for all sellers, such as bad weather or lower attendance, since we record visits based on seller past trends to then control how much funding needs to be held if the risk probability is too high. All such input variables can be entered into our vast data sets via machine learning models to measure the back-in-time accuracy so that models can be updated accordingly.\
Given our technical stack was native to the cloud from the outset and built with an API-centric approach, with our internal services decomposed into functions, we can now quickly rig machine learning (ML). From our data set, easy-to-use AWS ML services deliver a unique payment stack that reduces costs and risks for ticketing/reservation software companies. Most of our algorithms are regression-based to help score a risk based on many variables to help us price and control seller funding.
Our JSON-based rich transaction data sets are pushed to S3 for frequent import into the Amazon SageMaker IDE Studio via Datawrangler so we can compare our training models with accuracy against past fraud on our network. Once we are comfortable with the accuracy of the models, we will work to include the inference rules into our payment acceptance flows to help either present hard-to-overcome challenges in the checkout flow or flag asynchronously for manual review of potentially fraudulent transactions. Our logging infrastructure triggers alerts that we can then use to refine our model and runtime code.
We aim to make any ISV in the event/ticketing management space stronger financially by owning payments and delivering better-embedded payment features. We will do this with stronger connections from QR codes to payments, online or at POS, and access control with ticket scanning. This will create a better consumer experience and spur innovation, similar to when airlines embraced digital technology and the internet. Much of this new value creation will be enabled with AI that will make sense of near-perfect access to information anytime and anywhere.