Beta This is new guidance. Complete our quick 5-question survey to help us improve it.
Protecting your service against fraud
When you’re designing and managing your digital service, you must:
- consider how it could be attacked by fraudsters (start at the alpha stage)
- protect your users and your service as much as possible from fraud attacks
This guide covers the basics of fraud attacks. If you need to know more, talk to:
- a security expert in your organisation, if there is one
- an external security expert, if there’s no expert in your organisation
Meeting the Digital Service Standard
Types of fraud attacks
Fraudsters that attack online services usually try to:
- take money from a service
- pretend they’re eligible for a service
- extract information to attack other services
- use a service for money laundering
Some of these attacks are more severe than others. For example, a high-level fraud attack would be organised crime targeting multiple services to get money. A lower-level attack could be one member of your staff taking advantage of a vulnerability in a system.
Some attacks which seem small may lead to more serious consequences beyond your service or organisation. For example, if someone faked a claim for one service, they could use that fake eligibility to defraud another service.
Consider the weaknesses of online services
If you’re moving an offline service online, you should consider any new weaknesses that may be introduced in the process.
Online services are more open to attack and fraudsters can try multiple attacks in a short space of time.
Don’t assume any security processes you’re following offline will fully protect your service from fraud when the service moves online.
Consider non-financial fraud
Even if your service doesn’t pay out money to users, fraudsters may still try to attack it to get information which they could use to commit fraud.
For example, they could use your users’ personal details to access money or other benefits from other government services, the private sector or individuals.
Protecting your service against fraud
Follow these steps to protect your service against fraud.
Analyse the risk.
Reduce the risk.
Respond to changing threats.
Check information against independent sources.
Make your team aware of fraud risks.
Analyse the risk
You must start considering fraud risks during your service’s alpha phase.
As you build your first prototypes, you should investigate the potential areas of your service that could be left vulnerable to fraud.
For example, focus on parts of your service where users have to share personal information. Widgets or forms may ask users for information that’s attractive to fraudsters, particularly if a user is prompted to change their address or bank details.
Once you’ve found how your service gathers sensitive information, check how individuals or systems store, transport or access this data.
Reduce the risk
You must attempt to reduce the fraud risks that you’ve identified.
The way to reduce these risks depends on your service and the type of fraud that it could be affected by.
For example, if your service doesn’t usually receive requests from non-UK users, you could set up a system to check any of these non-UK requests and review them in detail.
If you know that certain payment mechanisms have higher fraud rates, you might treat them as higher risk.
You could also check that a user’s browser and IP address matches their usual browser and IP address. Sudden changes might be a sign of fraudulent activity and you may wish to treat them as higher risk.
You don’t need to automatically prevent a transaction because of a change in browser or IP address. Depending on your service and what it does, you could delay or record it, or require other forms of verification to process the request.
Respond to changing threats
Fraudsters regularly change the nature and frequency of attacks, so you should make sure your service is flexible enough to respond to changing threats.
For example, if you’ve set rules to limit fraudulent activity, make sure you can change them easily and that they aren’t ‘hard-baked’ into your system.
Your organisation may use security classifications to label security risks. If you apply these classifications to attacks, make sure you can change them according to the severity of new threats that appear.
Check user information against independent sources
You should check the information users give you against authoritative lists. For example, you can reference lists of authorised bank accounts, addresses and other personal details to identify any false information.
Be aware that not every incorrect entry means fraudulent activity. Users can make genuine errors and you should take these into account when checking against reliable and independent sources.
Make your team aware of fraud risks
You must make sure every member of your team understands the risk of fraud to your service so that they don’t add vulnerabilities by mistake.
While designing and maintaining your service, talk to security experts regularly to help reduce the risk and impact of fraud.
Monitoring your service for fraud
You should monitor your service for suspicious behaviour to help you identify fraudulent activity.
You can use ‘transaction monitoring systems’ to track user behaviour and spot suspicious activity.
Use the information you find to:
- stop fraudsters from getting into your service
- identify fraudulent activity after it’s been completed
- trace fraudsters and begin legal proceedings against them if possible
Keep a log of attacks
You should keep track of all fraud attacks alongside your security and risk log. Note the time, date and type of attack as well as whether it was successful.
Fraudsters will often try an attack, change tactics and try again. Wherever possible, you should share information about fraud attacks with other government agencies and departments to raise awareness.
The Cyber-security Information Sharing Partnership can help you exchange this information with others. Check with your security expert if you are unsure if it’s safe to share information about fraud attacks.
You may also find these guides useful:
- Published by:
- Technology community (technical architecture)
- Last update:
Guidance first published