Defensive OSINT: Verifying Identity to Prevent Fraud

Defensive OSINT helps you check an unexpected identity claim before you send money, share sensitive information, or grant account access. The most useful question is not whether a profile looks convincing. It is whether you can independently connect the person, organization, communication channel, and requested action.

A real company can be impersonated. A genuine email account can be compromised. A plausible video call can leave the caller’s authority unresolved. This guide explains a practical verification workflow for individuals and small organizations, with Canadian resources, examples of common mistakes, and tools that support a decision without pretending to guarantee safety.

Expanded November 5, 2026 with AI assistance and review of linked primary guidance. Examples are hypothetical and do not allege wrongdoing by any identifiable person or company.

The four things you need to verify

Separate four claims that are often blurred together. First, does the named organization exist? Second, is the sender actually associated with it? Third, did the organization authorize this particular request? Fourth, are the payment or access details correct?

A corporate registry can help with the first question. It generally cannot answer the other three. A company’s website may confirm that a person works there, but an impersonator can copy that information. An email from a familiar account may still contain a fraudulent payment instruction if the account has been compromised.

This distinction changes the investigation. You do not need a dossier on a stranger to decide whether to pay an invoice. You need enough reliable information to establish the correct counterparty and verify the requested transaction through an independent channel.

Step 1: pause the requested action

If a message asks you to change payment details, reveal a one-time code, open an unexpected file, or move the conversation to a new channel, pause that action while you verify it. A delay for confirmation is a normal business control, not an accusation.

Do not use the suspicious message itself as the only route to verification. The FTC’s business-impersonator guidance advises against following unexpected links or calling the numbers supplied in such messages. Find a trusted contact route independently.

For an existing supplier, use contact details already held in your approved records. For an unfamiliar organization, navigate to its official site through a route you can check and compare it with appropriate primary records. Be cautious about treating a sponsored search result as independent confirmation.

Urgency should affect your internal response time, not eliminate verification. A request that claims the normal contact is unavailable should move to an alternate approved process. It should not create a new exception that the requester controls.

Step 2: preserve the request and identify the exact claim

Keep the original message, relevant attachments, and a record of what was requested. In an organization, follow the established reporting process rather than circulating the suspicious material broadly. A screenshot is useful for quick communication, but the original message can contain information a security reviewer needs.

Write a neutral summary: “The sender requests that the next invoice be paid to a different account.” Avoid turning it into “The supplier is stealing funds” before the request has been investigated. The distinction protects both the decision and the quality of the evidence.

Record the claimed name, organization, role, domain, contact details, and relevant reference numbers. Compare exact spelling and identifiers. A familiar logo or display name does not establish that an address belongs to the organization it resembles.

Keep sensitive financial details out of public research tools. It is rarely necessary to upload an entire invoice, identity document, or private conversation to investigate a domain or check whether a business is registered.

Step 3: examine the domain without overinterpreting it

Read the actual domain carefully. A display name can say “Accounts Department” while the address belongs elsewhere. Similar spelling, added words, and misleading subdomains can make an unrelated address look familiar at a glance.

Use a registration lookup to inspect available domain information. ICANN identifies RDAP as the definitive registration-information service for generic top-level domains from January 28, 2025. Its Lookup tool is a practical starting point for public registration data.

A very recent registration can be inconsistent with a claim that a specific domain has represented a business for decades. It is a reason to investigate, not proof of fraud. An established business may launch a new domain, and an old domain may change ownership or be compromised.

Redacted registrant information is not itself suspicious. Privacy protection is common. Similarly, a secure connection or a padlock does not establish who controls the business behind a website. It addresses the connection to that site, not the truth of the site’s claims.

Step 4: verify the organization in the right registry

For a Canadian business, identify the claimed legal name and jurisdiction. Corporations Canada’s federal search confirms records for corporations within its stated coverage. Its page explicitly explains that provincial, territorial, foreign, and certain financial-law corporations are outside that database.

Use Canada’s Business Registries or the relevant jurisdiction’s official registry when federal coverage does not fit. A missing federal result does not establish that a business is fake. It may be registered elsewhere, operate under a different legal name, or fall outside the database.

Compare identifiers rather than names alone. Two organizations can have similar names. Check the corporation or registration number, legal status, and available dated records. Record which registry you searched and when, especially if you rely on a negative result.

A successful registry match establishes a limited fact about a registered entity. It is not a guarantee of solvency, honest conduct, product quality, or authorization of a particular sender. Keep the finding within the registry’s actual evidentiary role.

Step 5: confirm authority through an independent channel

This is the decisive step for many payment and access requests. Contact a known person or official service channel using details obtained independently of the request. Ask them to verify the specific action, not merely whether the named employee exists.

The FBI’s business email compromise guidance recommends verifying payment and account changes in person or through a known phone number. The practical value is that the attacker should not control both the request and its confirmation.

A reply within the same email thread may not be independent if an account or mailbox is compromised. A phone number added in that thread may belong to the requester. A second profile supplied by the same person may simply repeat the same false identity claim.

For an organization, record the approved verification method, who performed it, and who authorized the resulting change. Keep payment approval separate from the public-source research so that finding a plausible company record does not automatically release funds.

Worked example: a supplier changes its bank details

A fictional supplier has sent legitimate invoices for several months. A new message arrives in an existing thread, saying the supplier has changed banks and asking for urgent payment. The invoice design, company name, and staff signature all look familiar.

The staff member pauses the change and compares the request with the approved supplier record. A registry search confirms that the company exists, but that does not resolve the payment instruction. The staff member calls the established accounts contact using a number stored before the suspicious message arrived.

Suppose that contact says no bank change was requested. The organization preserves the message and follows its incident process. It does not need to decide whether the sender used a lookalike domain or compromised mailbox before refusing the unverified change.

Now suppose the contact confirms a legitimate change. The organization still follows its normal approval process and records the confirmation. The control works in both outcomes: it avoids a fraudulent transfer without treating every administrative change as evidence of wrongdoing.

The lesson is that background checks and transaction verification do different jobs. A fraudster can copy every public detail of a real supplier. Independent confirmation addresses the action that could cause the loss.

Checking recruiters, profiles, and claimed representatives

For a recruiter or unfamiliar representative, verify the claimed role through the organization’s established channels. Ask whether the opportunity or project exists and whether the person is authorized to discuss it. Use an official careers page or known switchboard where appropriate.

A reverse-image search can reveal that a headshot also appears under another name or in a stock-photo collection. Google’s image-search guidance explains how to search with an image. Treat matches as leads to inspect, not as an automatic identity verdict.

No search result does not prove a headshot is original. A matching picture can also appear in legitimate syndication, an author biography, or a copied profile made by someone else. Establish chronology and context before interpreting reuse.

Profile age, post history, and mutual connections can be copied, purchased, or misunderstood. They may help identify inconsistencies, but they do not replace confirmation by the organization the person claims to represent. Avoid collecting unrelated personal details as a substitute for that missing confirmation.

What email authentication tells you—and what it does not

Technical checks can help a qualified reviewer assess how a message was delivered. They should be interpreted with the actual sender domain and mail path in mind. A domain controlled by an attacker can use correctly configured authentication, and a legitimate account can send a malicious request after compromise.

For a nontechnical reader, the operational conclusion is simple: do not treat a “passed” authentication result as approval to transfer money. Route technical questions to your mail or security administrator while independently verifying the requested action.

Likewise, a forwarded message or unusual delivery route can complicate authentication results. A failed check deserves investigation, but it is not sufficient by itself to identify the sender’s intent. Keep technical observations separate from a conclusion about the person or business.

A practical tool and resource checklist

Resource	Useful question	Important limit
ICANN Lookup	What public registration data is available for this domain?	It does not establish that a transaction is authorized.
Official corporate registries	Does the claimed legal entity appear within the registry’s coverage?	Existence is different from legitimacy of a particular request.
Reverse-image search	Where else does this picture appear?	Reuse requires context; no result proves nothing.
Your approved contact directory	Can a known channel confirm this exact action?	It must be maintained and independently established.
Internal incident reporting	Who can preserve and assess the request?	Forwarding widely can expose sensitive data or confuse the evidence.

Use the smallest set of tools that resolves the question. Paid intelligence platforms can be appropriate for specialist teams, but an official registry and a verified callback are often more relevant to a small organization than an elaborate profile search.

Build a repeatable pre-transaction record

Create a short form with the requested action, claimed organization, source message, independent contact route, verification result, reviewer, and final decision. Include a place for unresolved discrepancies. This record helps the next staff member understand what was checked without repeating the investigation.

Use plain outcomes such as “confirmed through approved contact,” “not confirmed,” and “requires escalation.” Avoid assigning a universal fraud percentage from a handful of public signals. Such a score can look authoritative while concealing assumptions about domain age, incomplete registries, or name matching.

Set an escalation rule for changes to bank details, new high-value counterparties, and requests involving sensitive access. The exact policy should reflect your organization’s responsibilities and normal approval controls. Public-source research supports those controls; it does not replace them.

If you already sent money or information

Move from research to response. The Canadian Anti-Fraud Centre’s victim guidance outlines steps including documenting the incident, contacting relevant financial institutions, and reporting. Use its current instructions for the circumstances that apply to you.

For a suspected business-email-compromise transfer, the FBI also advises contacting your financial institution immediately. Do not spend the critical response period trying to identify the attacker from public records before notifying the organizations that can act on the account or transaction.

Preserve the evidence and be alert to follow-up approaches promising guaranteed recovery. Someone who knows details of the first incident may be exploiting information already disclosed. Verify any new service or authority through an independent route.

Frequently asked questions

Does a new domain prove that a business is fraudulent?

No. It may contradict a specific claim about that domain’s history, but legitimate businesses also register new domains. Use the discrepancy to guide further verification rather than making a public accusation.

Does a video call prove the caller’s identity?

No. Appearance and voice do not establish authorization for a transaction. Use known contact channels and verify the exact request. For media-specific questions, see the synthetic-media verification guide.

What if I cannot verify the request?

Record the unresolved issue and do not treat uncertainty as confirmation. Escalate through your normal process or wait for an approved contact route. You can decline an unverified action without claiming that the sender has committed fraud.

Sources and related reading

The official resources above support the tool descriptions and prevention or response guidance. The transaction workflow, fictional supplier example, and verification form are editorial applications for readers.

Explore the OSINT Research Hub, Privacy Page, and Start Here guide. Before the next consequential request, establish one independent way to verify it. That habit is more valuable than relying on a convincing profile.