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.
In short: Fraud prevention here means the defending side: reproducing a suspicious signup, reading what the network behind an address says, and testing your own risk rules from outside your own network. A static address registered to a named internet provider gives you a controlled case, because its registration is known and it does not move, so a changed result means your rules changed.
A hosting range is a block of addresses registered to a hosting or cloud company; a consumer range belongs to a provider that sells connections to households. Step-up authentication is the extra check, such as a one-time code, that a service asks for when a sign-in looks unfamiliar.
What an address tells a risk system
Every public address sits inside an autonomous system, a group of address blocks run under one routing policy (RFC 1930), and who holds each block is public record that the regional internet registries publish over RDAP, the newer alternative to WHOIS described in the RIPE NCC’s RDAP documentation. From those a lookup can tell which organisation holds an address and what kind of network it is, and reputation from earlier activity is layered on top. None of it identifies a person, which is why a rule built on it needs testing. This page explains how those signals work; we have no measured detection or approval rates and quote none.
WHERE IT APPLIES
Six things you cannot do from inside your own network
See what the network behind an address says
Many risk checks start from which network announced an IP and what kind of network it is. Working from a known address registered to a named internet provider 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.
WHO THIS IS FOR
Who reads this page
Fraud and risk teams
Reproducing a suspicious signup and reading what the network behind an address says.
Trust-and-safety teams
Finding out how their rules treat a legitimate connection from an internet provider's range in a given market.
Engineers who write the rules
Testing their own risk rules from outside their own network, so a changed result means the rules changed.
STEP BY STEP
A controlled test of one rule
Write down the rule and the outcome you expect
For an outside connection from an internet provider’s range: allow, challenge or refuse.
Buy one address in the market the rule concerns
Look it up in your own risk tools before testing.
Run the flow the rule guards
Signup, sign-in or checkout — from a fresh browser session, with test accounts made for the purpose and never a real customer’s details.
Record the outcome
Any step-up challenge, and the time.
Change the rule
Repeat the same flow from the same address, profile and account state.
WHAT A CONTROLLED CASE NEEDS
Properties that matter for this job
-
Known registration
- A named 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; 73 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 scripted 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, in section 5, prohibits “fraud, deception, theft, payment abuse, card testing” outright, and section 2 asks you to state a lawful basis before we open access to work that collects 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 makes automation plausible; a consumer provider's range makes a household 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 internet provider's range is being refused. If it stops the work rather than informing it, and that is the target you named when ordering, we replace the address free on request, up to 20 % of the order per calendar month. Terms of Service
An outside address reproduces the network, not the rest of a session: device fingerprint, behaviour and account history are still yours to vary, and a signup from a mobile carrier cannot be reproduced here while mobile is not on sale. When the question is how your rules treat a legitimate connection from an internet provider’s range in a given market, this is the right tool; start with one address per market your rules treat differently.
Sources
- RFC 1930 — autonomous systems — a group of address blocks run under one routing policy
- RIPE NCC — Registration Data Access Protocol — RDAP, how the registries publish who holds each address block