Reducing SNAP Fraud

The USDA, United States Department of Agriculture, has the SNAP, Supplemental Nutrition Assistance Program, which is a beneficial government assistance program providing necessary aid to many American citizens. Families rely on this funding to afford their monthly grocery items. With the program’s accessibility, fraud from adversaries attempting to benefit is growing and persistent. Stealing funds from people who need it the most really sucks, but it is a reality that must be considered when providing these programs. The community as a whole, including individuals who are not SNAP recipients, loses trust in the program when scams are successful. Implementing certain security measures may be difficult when the fraud protection resources need to quickly learn about new scams to defend against them. This article will present a proof of concept to initiate a discussion of how some public programs should integrate blockchain-based identity systems to help combat fraud. Like the USDA SNAP program, the EBT (Electronic Benefit Transfer) payment system could reduce fraud by allowing recipients to handle some of their fraud attacks independently. This could benefit public fund distribution programs, some real-world tokenized assets programs, and some blockchain-enabled device identity use cases.

Current SNAP Problems

Recently, there have been reports from SNAP recipients who were frustrated that their benefits were depleted before they had a chance to redeem them. This caused the community to spread unconfirmed narratives that government officials must be pocketing the funds for themselves. In some cases, it was challenging to have stolen funds returned, as the fraud protection resources struggled to keep up with new scams. Scammers do not target the government program systems directly, they target recipients in multiple ways.

The USDA uses different third-party providers for the EBT payment system. This allows the program to integrate with the current payment infrastructure, but it is not like credit card systems. Recipients can open new fraud cases through the USDA, but until investigations are complete, the recipient may not have funds returned. Requesting to have portions of the stolen funds credited during the investigation is not an option, as many credit card issuers allow. Recipients do not have a bank account with a balance, just an account with the USDA with limited privileges.

The most probable cause for the inefficiencies recipients are facing could stem from two popular attacks, phishing scams and card skimming. The goal of these attacks is to trick actual recipients into exposing their information, which allows the scammers to divert funds to themselves without the recipient knowing. Phishing scams solicit email messages or text messages with links to webpages disguised as legitimate registration portals. The fake webpages present an authentic-looking USDA registration form to mislead applicants who are not savvy enough to spot fakes.

The card skimming attack occurs at a merchant’s payment terminal. The point of sale machine is compromised by placing an identical fake skimmer on top of the legitimate point of sale machine. The merchant could be the attacker, or an individual could be placing a skimmer at multiple locations without the merchants knowing. Once a skimmer is placed, it is difficult to spot at first glance. The card information is taken when the user swipes their EBT card, and then purchases are made at different locations until the account is depleted. This can all happen within the same day that the card information is taken. It is difficult to identify the attacker as the owner could refute any allegations of placing the skimmer themselves. It is not like the funds are diverted to a bank account registered in the merchant’s name. Scammers are aware that targeting recipients with this method has a higher success rate, so this popular attack will become more sophisticated.

The Proposed Solution

Government programs should prepare to integrate blockchain protocols across their systems. Centralization of all processes for most government public programs creates opportunities for fraud, corruption, or malicious attacks. In many cases, centralization is the main reason why some attacks are possible. Blockchain-based systems are still in their early stages of adoption, so it may be a hard sell for government programs to integrate blockchain-based systems. For example, to combat the popular fraud attacks mentioned, the public programs should integrate a blockchain-based identity layer. In this system, stablecoins on the Circle’s Arc blockchain can be leveraged for predictable on-chain fees. Smart contracts introduce a transparent identification system for the issuer, the qualified merchants, and the approved recipients. The program’s activities, such as funding distributions, can be easily viewed by all participants and would not require additional resources.

The proposed solution is not a replacement for the current SNAP system but an added security layer that could help reduce fraud, lower the fraud protection resource allocation requirements, and improve trust in the program. When stablecoin payments are inevitably adopted, the transition will also be easier if this solution were already implemented.

A SNAP Trust Layer

The implementation introduces three roles in the system as identities on-chain. The issuer, which is considered the USDA SNAP program in this use case. The merchant and the recipient, who are approved by the issuer. On the Arc blockchain, the issuer will mint an ERC20 equivalent to the amount of funding being allocated by the SNAP program for a given period. For example, if in the month of June SNAP recipients receive 5 million dollars in funding, the issuer should mint 5 million tokens. If stablecoins were adopted, the USDC would be staked directly on the system, and a synthetic token would be minted. Now the program will have a public record of the funds that have been distributed. Different parties could start their own investigations about the program’s activities based on the on-chain data before sharing narratives with no evidence.

An applicant should own a digital wallet compatible with the Arc blockchain. Private key management is the responsibility of the applicant. During the registration process, applicants will share the wallet’s public address with the issuer, who will store it in the applicant’s profile in the current system. The core smart contract used in this system is the ERC7425, tokenized reserve standard. This contract will record staked tokens representing funding rounds being allocated. The proposal will mint the equivalent amount in reserve tokens and send these tokens to an interaction contract. The interaction contract will know all registered identities and record any transactions made by recipients to merchants. The issuer is the owner of all contracts in the system, which means neither the merchant nor the recipient will have transfer authority directly. For more technical details on the tokenized reserve proposal, read my introduction article here, as I will not dive into the details in this article.

Payment Simulation

Each EBT payment uses traditional banking payment rails to settle merchant transactions. Before recipients are able to make transactions, the issuer is required to authorize an amount of spendable funds for that recipient. The EBT system approves new transactions by first checking if the recipient is within its approved allowances.

When an issuer sets allowances on their current system, the identity contract will also be updated on-chain through the identity contract. The simulation in this implementation requires the recipient to update the state after the issuer sets the allowance. In a real-world implementation, this could be changed to a more efficient method. The issuer will use smart contracts to record new information or use them to reference information about each recipient and merchant identity. If the recipient sets access control preferences on-chain for their card, each transaction should call the on-chain contract to check if the transaction violates the current preferences set. If it is being violated, the contract will return the violation to the issuer’s system, allowing the issuer to reject that transaction. Setting preferences on-chain does require a transaction fee each time a recipient updates their preferences. Limiting the amount of preference updates, like setting only during registration or having the issuer pay for fees related to updates, are some approaches to improve the user experience. Other supported features could include notifications to the recipient, either through messaging applications or email, about a recent violation. Recipients need a safe, secure way to monitor their card activity.

Why is this Protection

A smart contract will register an identity for all participants. These identities provide an entry point for public investigation. To protect from phishing attacks, the applicant should be identified with their registered identity during registration. The registered wallet should not be requested from the recipient outside of registration and setting preferences. For a new applicant with no on-chain identity, if their registration is compromised by an attacker who already registered a public address with the applicant’s information, the current procedure to recover their account through USDA should be used, as they never successfully registered. If the first registration is successful, the issuer now has a registered address for the applicant. This address will be used for renewal applications, and if the recipient wants to register a new public address. If the applicant does not have access to the registered wallet, then they can repeat the registration process through the USDA.

During a phishing attack, the attacker may successfully steal all the applicant’s private information, but the wallet information becomes a second attack vector. The attacker would need to create a second attack that targets applicants’ wallet keys directly. This attack is more difficult than the webpage portal phishing attacks, as asking for a signature from the wallet is not a requirement. The applicant has to have access to the wallet, as part of the registration occurs on the identity smart contract. This proposal does not defend against attacks that target keys, but an added benefit to the program is that stolen keys become public now that registration occurs on-chain. The nature of the public program requires applicants to conduct recurring applications, which means recipients can check the status of their SNAP account often. This will allow an applicant to know if the keys were compromised more quickly compared to web3 applications, where the victim needs to check balances, but the attack could occur at any moment.

For the card skimming attack, the identity contract records each recipient’s access control preferences. This includes transaction limits, approved merchants to interact with, or the time window to use the card. This approach makes every card interaction unique. During a card skimming attack, the attacker will not know what preferences are set for each card that was stolen. The probability of the card being declined is higher since access controls can be triggered. If the attacker is still not deterred by the unknown probability of a card being declined, their window to execute a successful attack is narrow. The recipient could directly receive notifications of an unknown successful transaction and block their card.

Summary & Future Work

The current implementation does not address problems like privacy, attack scenarios involving stealing private keys, the true cost savings, or the user experience. If this proposal were able to influence a real-world implementation for programs like SNAP, these pain points should be addressed. Other work that could be explored is purchase traceability, where the recipient can track what items they have purchased in the past. This could allow the recipient to monitor item price changes or control diet intake. Currently, the proposal aims to demonstrate how all participants within a program can publicly view associated activities like fund issuance or transaction violations. Recipients are able to set access controls for their associated physical cards to help prevent card skimming attacks, while the introduction of a blockchain digital wallet reduces the possibility of successful phishing scams. Check out the repository here.