Reproduce a flagged signup
An analyst reading a log is reconstructing a session from its shadow. Replaying the same route from a comparable network turns an argument about what probably happened into a recording of what does happen.
FRAUD PREVENTION
Test your rules from outside your network
Risk systems are written by people sitting inside the network they are protecting, and then tested from that same network. This scenario is the other chair: reproducing what an outside connection looks like, and finding out what your own rules do with it.
This is the defensive half of the subject. We are not in the business of helping anyone look like a customer they are not, and our acceptable use policy is specific about that.
Fraud prevention is the reverse of every other scenario on this site. The other four are about how your own traffic looks to somebody else. This one is about reading the network behind somebody else’s signup, payment or login. The question a fraud team asks about an address is what it is registered to. A hosting range behind a consumer signup is a signal worth acting on. A carrier address behind a consumer signup is not, on its own, anything at all. Telling those apart is the job, and it is why the catalogue names the provider behind every block rather than only the country. A static address helps in two ways. It lets you exercise your own rules from a known, unchanging vantage point, so that a rule change is the only variable in the test. And it lets you see what a given market looks like from inside it, rather than inferring it from whatever reaches you.
WHERE IT APPLIES
Six things you cannot do from inside your own network
See what the network behind an address says
Most risk decisions turn on who announced an IP and what kind of network it is. Working from a known, named, consumer-registered address gives you a controlled case to check your own lookups against.
Calibrate the rules you already run
A rule that refuses hosting ranges and a rule that refuses everything unfamiliar behave identically until you test them separately. A deliberate, known outside address is how you tell which one you wrote.
Check geography rules honestly
If your system treats a market as high risk, someone should find out what that actually does to a legitimate customer there before the customer does. Testing it needs a connection in that market.
Exercise step-up authentication
Additional verification that triggers on an unfamiliar network is only correct if you have watched it trigger. From your office it never will, because your office is the familiar network.
Watch a rule change land
Deploying a risk rule and observing the effect from outside, on the same address each time, is the difference between a controlled change and a change you learn about from the support queue.
WHAT A CONTROLLED CASE NEEDS
Properties that matter for this job
-
Known registration
- A named consumer internet provider, so the lookup result is a known quantity
-
Stable identity
- One address for the period, so a result changing means your rules changed
Market selection- Country chosen at checkout; 74 in the catalogue
Rotation- None — a moving address makes every before-and-after test unreadable
-
Access control
- Username and password, or an IP whitelist for a test runner
Protocols- HTTP, HTTPS and SOCKS5, so browser and headless runs use one address
RELATED
Other scenarios, and the product itself
FAQ
Questions about fraud prevention
Is this about committing fraud or preventing it?
Preventing it. Everything on this page is written for the person defending a service: reproducing a case, calibrating a rule, watching a change land. Our acceptable use policy prohibits fraudulent activity outright, and separately asks for a lawful basis before we open access to work involving personal data. If what you need is to look like a customer you are not, we are the wrong supplier. Acceptable Use Policy
What does a risk system actually learn from an IP address?
Mostly two things: which network announced it, and what that network is for. A hosting company's range says automation is plausible; a consumer broadband range says a household is plausible. Layered on top is history — whether that specific address has been seen doing something unwelcome before. None of it is proof of anything, which is why a rule built on it needs testing rather than trusting. Residential vs datacenter
Why do I need a proxy to test my own rules?
Because you cannot be outside your own network from inside it. Your office address is on every allow-list you have ever written and has years of good history against your own service. Testing an unfamiliar-network rule from the most familiar network you own tests nothing, and the first real proof arrives as a complaint.
Should the test address rotate?
No. A before-and-after test needs one variable, and if the address moves between runs you have two. Buy one address per market you are testing and keep it, so a different outcome next week is a change in your system rather than a change in your vantage point.
Can I use this for security testing against another company's systems?
Only with that company's written authorisation, which our policy asks to see before opening access to that kind of work. It is one of four things on a short verification list, and it is there because the legal exposure of unauthorised testing sits on both of us rather than only on you. Acceptable Use Policy
What if the test address itself gets flagged?
That is occasionally the most useful outcome you can get, since it tells you a legitimate consumer range is being refused. If it stops the work rather than informing it, tell us the target and we replace the address free, up to 20 % of the order per calendar month. Terms of Service