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. Anti-fraud monitoring needs no prior approval under our acceptable use policy, though a short verification list in section 2 applies to some targets, financial services among them. The same policy prohibits fraud itself, so we do not help anyone look like a customer they are not.
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 on a named internet provider’s network gives you a controlled case, because its network is known and it does not move, so a changed result points first at your rules, once you have checked that the address’s own rating has not moved.
A hosting range is a block of addresses registered to a hosting or cloud company; an access provider’s range belongs to a company that sells internet connections to homes and businesses. Step-up authentication is the extra check, such as a one-time code, that a service asks for when a sign-in looks unfamiliar.
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.
An analyst reading a log is reconstructing a session from its shadow. Replaying the same route on your own service, with a test account and from a network of the same kind, turns an argument about what probably happened into a recording of what does happen.
Many risk checks start from which network announced an IP and what kind of network it is. Working from a known address on a named internet provider's network gives you a controlled case to check your own lookups against.
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.
If your system treats a market as high risk, someone should find out what that does to a legitimate customer there before the customer does. Testing it needs a connection in that market.
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.
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.
Reproducing a suspicious signup and reading what the network behind an address says.
Finding out how their rules treat a legitimate connection from an internet provider's range in a given market.
Testing their own risk rules from outside their own network, on an address whose own rating they have checked first.
For an outside connection from an internet provider’s range: allow, challenge or refuse.
Look it up in your own risk tools before testing, and in the IP checker to see how published blocklists and fraud-scoring services already rate it.
Signup, sign-in or checkout on your own service, in a staging or sandbox environment where you have one, from a fresh browser session. Use test accounts made for the purpose and your payment provider’s test mode, never a real customer’s details or anyone’s real card.
Any step-up challenge, and the time.
Repeat the same flow from the same address, profile and account state.
Known registration
Stable identity
Market selection
Rotation
Access control
Protocols
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
Mostly two things: which network announced it, and what that network is for. A hosting company's range makes automation plausible; an access provider's range makes an ordinary connection plausible. How a given address is classed is for the lookup to say, so check it rather than assume it. 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
Run it through the IP checker. Looking the address up in the four published lists it reads is free: Spamhaus DROP, FireHOL Level 1, blocklist.de and the Tor exit list. The full check also asks three fraud-scoring services and gives one verdict, with each source's reading beside it. Knowing whether the address already carries a public reputation helps separate it from your rule, though each site still applies rules of its own. The check runs in the ProxyJam app after you sign in, and the full check is charged to your wallet balance unless you have a free one: each delivered order includes one. IP Checker
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.
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 comes from your system or from the address's rating, and the IP checker tells you which of the two moved.
Only with written authorization from the owner of the target, which section 2 of our acceptable use policy asks to see before we open access to that kind of work. It is one of four items on that verification list; targets in financial services, healthcare and government systems are another. Acceptable Use Policy
That is occasionally the most useful outcome you can get, since it tells you a legitimate internet provider's range is being refused. Under section 2.5 of the Terms of Service, we replace an address free on request if it is blocked on the target you identified at purchase, up to 20 % of the addresses in the order per calendar month. A listing, or a refusal by your own rule, is not a ground on its own, and replacement is not available where the address became unusable through use our acceptable use policy forbids. Terms of Service
