Table of Contents
Screening users before granting software access is now a basic compliance step. If you run a SaaS product or sell software, you must check who your users are. Giving software or access to a sanctioned party can breach export and sanctions rules. This applies even when the product is free or cloud-based.
The good news is that the checks are simple to build. You screen at sign-up. You block sanctioned countries and parties. You re-screen your users over time. This guide walks through the practical steps, and it links to our denied party screening hub for deeper detail.
Why software firms have to screen users
Software counts as a good and a service under many trade rules. When you give someone a login, you provide access to that software. If that person or company sits on a government blacklist, you may have just broken the law.
Cloud access, downloads, and API keys all fall in scope. So do updates, support, and technical help. The rules do not care that the delivery is digital. They care about who receives the benefit. To learn what these programs cover, read our guide on what trade compliance means.
What you are screening against
You screen users against two things. First, restricted party lists. Second, sanctioned countries and regions. Both matter, and both need checks at sign-up.
Restricted party lists
Governments publish lists of people and firms you cannot deal with. These name individuals, companies, and vessels. A single match can stop a transaction cold. Some of the main US lists are below.
| List | Who runs it | What it flags |
|---|---|---|
| OFAC SDN List | US Treasury | Sanctioned people and firms |
| BIS Entity List | US Commerce | Parties of export concern |
| Consolidated Screening List | US government | Many lists in one search |
The Consolidated Screening List is a handy starting point. It pulls many US lists into one place. Other countries and the UN publish their own lists too.
Sanctioned countries and regions
Some countries and regions face broad sanctions. You often cannot serve users based there. This means blocking sign-ups tied to those places. You can use billing address, IP data, and stated country to spot them.
Screen at sign-up
The best place to screen is the moment someone signs up. You collect a name, a company, an email, and a country. Run those details against the lists before you grant access. If nothing matches, let them in. If something matches, hold the account for review.
Build the check into your registration flow. A clean workflow looks like this.
- Collect user and company details at registration.
- Check the stated country against your blocked list.
- Screen the name and company against restricted party lists.
- Grant access only when both checks are clear.
- Route any hit to a human for review before access.
For a fuller walkthrough of the checking method, see our guide on how to do denied party screening. It covers data quality, matching, and record keeping in more depth.
Block sanctioned countries and parties
Blocking is the action you take when a check flags a problem. You can block by country and by party. Both need a clear rule set your system follows every time.
- Reject sign-ups tied to sanctioned countries or regions.
- Freeze any account that matches a restricted party.
- Cut off access, downloads, and API keys for confirmed hits.
- Keep a record of why you blocked each account.
Watch for the ownership trap too. A user may not be listed, but a listed party may own most of their company. The 50 percent rule means that firm can be treated as sanctioned. Screen the company, not just the person.
Handle matches and false positives
Not every hit is a real problem. Common names produce many false matches. A person called John Smith is not the sanctioned John Smith. You need a review step to sort real hits from noise.
Compare more than the name. Look at the country, the company, and any date of birth. If the details do not line up, you can clear the account. If they do line up, keep access blocked and escalate. Our guide on false positives shows how to do this well.
Re-screen your existing users
A clean check at sign-up is not enough. Lists change often. A user who was fine last year may be listed today. So you re-screen your whole user base on a set schedule.
Run a full batch screen when the lists update. Screen again when a user changes company or country. For timing advice, read how often you should run screening. Building these checks into your product keeps you covered as things change. The denied party screening resource hub pulls the full method together.
Frequently Asked Questions
Do free software tools need user screening?
Yes. Free access is still access. Giving a sanctioned party a free login can breach the rules. Price does not remove the duty to screen.
What if a user passes at sign-up but is listed later?
That is why you re-screen. When a list update flags an existing user, freeze the account. Review the match, then cut access if it is confirmed.
What happens if we grant access to a denied party?
You can face fines and other action. The exact result depends on the case. See our page on penalties for dealing with a denied party.
Key Takeaways
Screening users before granting software access protects your firm and your customers. Screen at sign-up, block sanctioned countries and parties, and re-screen on a schedule. Keep records of every check and every block. Sort real matches from false ones with a human review step. If you want help setting up these checks, contact our team.