How it unfolds, step by step
The setup
An approach arrives. It may be a message, a call, an advertisement, or an introduction inside a group. It carries a name, a firm, sometimes a registration number and an image of a certificate. None of that is yet a fact about who is on the other side. It is a claim, handed over along with the request. Whether the market idea sounds attractive is a separate question. First check who is asking for the money.
What happens next
The checks run when a request crosses one of three lines. Money is to be sent. A permission is to be granted: a password, a one-time code, screen sharing, an unfamiliar app. Or a payment destination is named. Each line is checked through a route found independently. That means the organisation's own site, reached by the reader, and the official record. Never the link, number or address supplied by the person making the claim. That route only checks the sender against themselves.
What it means — and does not
A finished run says only that nothing came to light. It does not conclude that the person, the firm or the offer is genuine, and this page never will. A registration is a fact about a record. It is not an endorsement of what is being sold. A certificate is an image, and images copy. What the checks CAN do is surface a mismatch. A name that does not match the record. A service that is not the registered one. A payment destination that is a personal or unrelated account. A permission far wider than the transaction being discussed. A mismatch nobody can explain is enough reason to stop. Fraud does not have to be proved first.
What this does not establish
Make these checks before money moves. If money has already left, or someone else controls the account, report it promptly. An unauthorised debit in progress moves faster than a list of checks. It belongs with the bank's own reporting channel and the appropriate authority first. Keeping the messages and references matters more than finishing any checklist. Passing these checks does not establish that an approach is safe. The absence of a flag is not evidence. A fraud can pass superficial checks.
Things to check
6Was the contact route found independently, or supplied by the person making the claim?
Do the name, category and service on the official record match what is actually being offered? It is not enough that they exist somewhere on it.
Is the payment destination the provider's own documented account, or a personal or unrelated one?
Does the permission being asked for — a code, a screen share, an app — reach further than the transaction being discussed?
Is the only evidence of the money a balance inside the app that is holding it? A statement from the institution that would hold the assets is a different thing.
Remember: nothing on this list can return "safe". It returns a discrepancy, or it returns nothing found.
Common mistakes
5Treating a registration number or a certificate image as verification. Both copy perfectly, and neither says the service being offered to this reader is the registered one.
Calling the number printed in the message that asked for the money. That checks the sender against themselves, and it always agrees.
Reading a small successful withdrawal as proof the rest exists. It is the cheapest way there is to make a larger deposit feel tested.
Waiting until fraud can be proved before saying no. The decision point is a discrepancy nobody can explain, not certainty.
Reading a one-time code back to somebody offering to fix an account. The code is the authorisation itself. It is not a formality that comes before one.
Every item on the checklist comes back without a problem. What has that established?
- That the offer has been checked out, so the payment can go ahead
- That the person is registered, which is what the checks exist to establish
- That nothing surfaced
Show the answer
C. That nothing surfaced
A checklist surfaces discrepancies. It has no way of proving there are none. The tempting answer turns "nothing found" into "nothing there". That is exactly the conclusion a convincing approach is built to produce: the number is real, the certificate is a real image, the small withdrawal really arrives. The second answer fails one step earlier. Registration is a fact about a record, not an endorsement of what is being offered to this reader.
Frequently asked
3Does a registration certificate prove the sender is genuine?
No. A number and an image both copy. One check carries weight. Do the name, category, contact channel and service on the official record match what is actually being offered? And even a full match is only a fact about a register. It is not an endorsement of the offer, and not a promise about returns.
Does a small successful withdrawal prove an app is safe?
No. A small payment out proves that a small payment was made. It says nothing about whether any shares or funds exist behind a displayed balance. A first withdrawal that arrives smoothly is a recognised step before a much larger deposit is requested.
Is a one-time code ever safe to share with support?
The code is the authorisation. Passing it on passes on the action it authorises. A genuine provider has no need to have one read back to it. LearnNifty never asks for one either. No page on this site has a field for an account number, a PAN, a password or a document. Anything an official process needs belongs in that process, not here.