Onboarding · 6 min read

The client is on a VPN. Flag it, do not reject it

An IP address is a fact about a network, not about a person. Treating it as a verdict rejects honest clients and evidences nothing. Treating it as a question does the opposite.

A client completes your onboarding form. Everything checks out: the passport is genuine, the liveness check passed, the face matches the portrait. Then the declaration arrives from an IP address registered to a data centre in Frankfurt, and the client told you they live in Guernsey.

What should happen next?

A surprising number of onboarding systems answer this by refusing the submission. It feels like control. It is the wrong answer, and the reasoning matters more than the conclusion, because the same reasoning applies to every automated signal a compliance system produces.

What an IP address is

An IP address identifies a network interface at a moment in time. Looked up against a geolocation database, it yields the registered location of the network operator and, from a second database, the organisation that operates it. That is the whole of the information.

Notice what is missing. It does not identify a person. It does not identify a device. It does not identify a residence. It identifies a network, and the relationship between a network and a human being is loose enough to be nearly decorative.

Consider who is behind a commercial or hosting network on any given day. An employee of a firm that routes all staff traffic through head office. A partner working from home on a corporate laptop with an always-on tunnel. Anyone using a privacy product bundled with their antivirus subscription, or built into their browser, or switched on by default by their phone. Someone on hotel wifi that backhauls to another country. A resident of a jurisdiction where ordinary services are geographically restricted, for whom a tunnel is simply how the internet works.

Against that population, the base rate matters enormously. The overwhelming majority of people who reach your form from a commercial network are honest clients living entirely ordinary digital lives. A rule that rejects them all in order to catch the few will reject mostly honest clients, because that is what the arithmetic says it will do.

Why an automatic rejection is the wrong control

There are three separate problems with declining on this signal, and they compound.

It fails against the population it claims to catch. Someone deliberately concealing their location, having got as far as presenting a genuine document and a live face, is the one person in the set who will notice the rejection and simply try again from a residential connection. The control filters out the people who were not hiding and educates the one who was.

It is the wrong shape for the regime. The Handbook's risk-based approach, at Chapter 10, asks for judgement applied to the circumstances of the file and recorded. Non-face-to-face delivery is a recognised risk factor and it is treated as a factor, feeding into a rating, not as a gate that stops the process. A binary refusal by a machine is not a risk-based approach; it is a substitute for one, and it produces no reasoning for a file to carry.

It destroys the evidence. This is the one firms underrate. A rejected submission is a dead end. Nothing is recorded because nothing completed. Compare that with the alternative: the observation is captured, a human considers it, asks the client, receives an answer and records the answer. The second file now holds something an inspector can read, and the first holds nothing at all. The firm that refused looks more cautious and has strictly less evidence.

What the signal is genuinely good for

Discard the idea that the network tells you about the person, and something more useful survives: the network tells you about a discrepancy.

A client who states they are resident in Guernsey and submits from a Guernsey residential network has produced a small, quiet corroboration. Not proof, but consistency, and consistency across independent signals is what a strong file is made of. A client who states Guernsey and submits from a commercial network in another country has produced an inconsistency, and inconsistency is a question.

The question is almost always answered in one sentence. I was travelling. Our firm routes everything through London. I use a VPN on my laptop. Each of those is entirely satisfactory and each becomes a line on the file recording what was noticed and what was explained. On the rare occasion the answer is evasive, that too is a fact worth having, and worth having in writing.

The same logic extends beyond the network. Tax residency typed as one country while the passport says another. A stated address in one jurisdiction and a phone number from a third. None of these is a decline. Each is a prompt to ask, and each becomes stronger evidence once asked than it would ever have been as an automated rule.

Recording it without creating a new problem

Two practical cautions, both of which firms discover the hard way.

The first is that the flag must be visibly a heuristic. Identifying a network as commercial or hosting means matching the registered operator against a list of operators known to run data centres and tunnels, and a list like that is never complete and never perfectly accurate. If the interface presents its output in the same register as a sanctions match, staff will learn to treat it as one. Show it as a note, in a colour that means "look at this", never in one that means "stop".

The second is proportionality. Looking up an address to note a town and a network is a modest piece of processing with an obvious compliance purpose. Sending your clients' IP addresses to a third-party service to do it is a new data flow to a new processor, and it needs to appear in your privacy notice and your sub-processor list. There is an easy way to avoid the question entirely, which is to hold the geolocation database locally and do the lookup on your own machine. The same answer, no third party, nothing to disclose.

What Flarion does about it

Flarion records the address a declaration was made from and resolves it on the firm's own server, against city and network databases held on that machine and refreshed weekly. No client's address is sent anywhere to be looked up, which is why the lookup adds no sub-processor to the privacy notice.

The review screen shows the town, the country and the network operator beside the declaration. Where the operator is one that runs data centres or tunnels, the line carries an amber note. Amber, deliberately, and never red: it is a prompt to ask a question, not a verdict on a person, and nothing in the product will decline a submission because of it.

What the reviewer does next is the part that matters, and it is recorded. The observation, the question, the client's answer and the reviewer's conclusion go onto the file with a name and a time against them, append only. When an inspector asks how the firm handles a client onboarding from an unexpected country, the answer is a file that shows exactly that happening, which is worth considerably more than a rule that says it never happens at all.

See Flarion on your own client book.

Thirty minutes with the founder. Bring a spreadsheet export from your current system and leave with it loaded, screened and risk rated.

Book a demo