Loading
Nepal Will Do
On the ascent
From the world, to work in Nepal — every order protected by escrow
Legal · Money
Last updated 25 July 2026
Nepal Will Do is a closed loop. Money enters through a licensed payment gateway, sits with the platform while an order runs, and leaves only to a destination that has been checked — by the gateway on one rail, by a Nepal Will Do staff member reading a government ID on the other. Nothing moves between a client and a freelancer directly, because no such path exists in the software. Every balance change writes a ledger row, and every staff action writes an audit row.
This page describes those controls. It is not a statement of regulatory compliance — see the note immediately below, which is the most important paragraph here.
Everything on this page was read out of the code that moves the money, and it is accurate as a description of current platform behaviour. It has not been reviewed by a lawyer or by a compliance professional, and it should not be relied on as evidence that Nepal Will Do meets any particular obligation.
In plain terms, so there is no room for a generous reading — Nepal Will Do does not claim any of the following, and nothing below should be read as claiming them:
Compliance with Nepal's Asset (Money) Laundering Prevention Act, or with the FATF recommendations, or with any other anti-money-laundering or counter-terrorist-financing regime.
A registered or filed AML programme, policy manual, or documented risk assessment.
An appointed compliance officer, money-laundering reporting officer, or equivalent named role.
Sanctions, watchlist or politically-exposed-person screening of any user, in any form.
A suspicious-transaction or threshold-transaction reporting channel to any authority.
Customer due diligence or know-your-customer verification to any defined regulatory standard.
Those are deliberate omissions rather than oversights in the writing. Whether Nepal Will Do is required to operate a formal programme, and what that programme would have to contain, is a legal question that has not been answered yet.
Every control described below is traceable to code in this repository. Amber markers show where a commitment, a threshold or an obligation still has to be decided by someone qualified rather than guessed at here.
The shape of the system
The strongest control here is structural rather than procedural: there is no code path that sends a client's money to a freelancer. If a route does not exist, it does not need policing.
Checkout opens a payment session with Hamro Pay for the order amount plus the client service fee, and the platform collects it. Wallet top-ups run through the same gateway. There is no cash channel, no bank-transfer-and-tell-us channel, and no way to mark an order paid without a gateway transaction the platform can query by id.
A confirmed payment is held against the order for its whole life. Release is triggered by the client; if the client goes silent, an auto-approval releases it. After approval the funds sit for a further . Opening a dispute stops the money where it stands. Nothing about that sequence involves a second account.
Value leaves only as a payout to a checked destination, or as a withdrawal of a wallet balance through those same rails. Withdrawals have a minimum of . Refunds, dispute outcomes and negotiated settlements are not transfers at all — they are ledger entries inside the platform.
Why this matters more than any list of red flags
Identity
This is the part most easily overstated, so it is set out per rail. Three different checks exist on this platform, they are performed by three different parties, and none of them is a general identity verification of every user.
| The check | Who performs it | What it actually establishes | What it does not establish |
|---|---|---|---|
| Hamro Pay payout-number validation | Hamro Pay, the licensed payment provider. The platform asks; it does not decide. | That the destination number is an account Hamro Pay itself reports as verifiedon its own books — the status that governs that account's transaction limits with the provider. The identity work behind that answer is the provider's, performed under its own obligations as a licensed institution. | It is not a check on the Nepal Will Do account holder, and it is not performed for clients, for sign-in, or for anything other than a payout destination. |
| Government ID review on the remittance rail | Nepal Will Do staff, by hand. No provider API is called anywhere in this flow. | That a person on the operations team has read an uploaded government ID document and compared it against the declared legal name, the account-holder name and the bank account the money would be sent to, and then either approved or rejected the rail with a written reason. | It is a human document review, not a check against an issuing authority's records, and it happens only for freelancers who choose this rail. |
| SMS one-time-code verification | Nepal Will Do, through its own SMS provider (SpellCPaaS). | That whoever holds the account also controls that phone number, at that moment. It is compulsory before a freelancer can publish a gig, place a bid, or request a payout or withdrawal. | It proves control of a phone number and nothing about who a person is. A verified phone is not an identity document and this page does not treat it as one. |
On the Hamro Pay rail, a payout can only ever reach an account that Hamro Pay itself reports as verified. The platform sends the destination number to the provider, and if the answer is anything other than verified, the payout is refused rather than attempted. So the identity check standing behind that number is performed by a licensed payment provider, not by Nepal Will Do — and that is a genuine strength worth saying plainly, because it puts a regulated institution between us and the destination account.
What is nottrue, and is worth stating just as plainly: Hamro Pay does not perform Nepal Will Do's identity verification generally. It answers one question, about one payout number, on one rail. It does not vet clients. It does not vet freelancers who take the remittance rail — those government IDs are read by Nepal Will Do staff. It has no part in the SMS check, which is ours. Anyone reading “verification is handled by the payment provider” as covering the whole platform would be reading something this page does not say.
A client signs up with an email address and a password and can fund an order. No phone check, no document, no name check. That is a deliberate product decision — the client's money is the money at risk, and it is held rather than forwarded — but it is stated here rather than left to be inferred from the absence of a paragraph.
The exit
Each of these is a refusal in code at the moment a payout is processed — not a rule written in a document and hoped for. A payout that fails any of them does not go out.
Before a Hamro Pay transfer is attempted, the destination number must be recorded on the account as gateway-verified. That record is written in exactly one place in the codebase, and only when the provider's validation call answers verified. A number that has never been through that call cannot be paid to, and the payout is marked failed with that reason.
A number already verified as a payout destination on another account is refused — checked when the number is registered, and checked again at payout time, not merely at registration. That closes the gap where a number is registered legitimately and later reused to funnel several accounts' earnings into one destination.
Changing a payout destination starts a cooldown, and a payout falling inside it is deferred to a later sweep rather than sent. The owner is emailed when the number changes. This is the account-takeover control: take a session, repoint the destination, cash out immediately — the cooldown is what breaks the last step, and the email is what surfaces it.
Submitting remittance details creates a rail marked pending staff review, never usable. A staff member compares the uploaded government ID against the declared legal name and the destination bank account, and approves it or rejects it with a mandatory written reason. Only a rail marked verified can be paid to.
A verified rail whose account number, account-holder name, receiver legal name or provider changes is pushed back to pending staff review and held for 24 hours, and its previous verification is cleared rather than carried over. Cosmetic edits — a city, a branch, a contact phone — do not trigger it, so the control fires on the fields that decide where money lands.
Two phone numbers exist on an account and the code refuses to let them do each other's jobs. The gateway-verified payout number is never used for sign-in, one-time codes or account recovery. The SMS-verified number is never used as a payout destination. A compromised inbox or SIM therefore does not hand over a payout path.
One further brake, described in full on the escrow page: an account whose trust ledger has triggered a payout delay has its queued payouts held back until the delay elapses, and the delay is written onto the payout's own timeline so the reason is visible rather than mysterious.
Watching, and remembering
Detection here is narrow and honest about its limits. It looks for attempts to move the money off the platform, and it records money and staff actions in a way that cannot be quietly rewritten.
Order chat is scanned for the patterns that precede an off-platform deal: phone numbers, email addresses, outside messaging apps, external social profiles, and the names of rival payment methods or a request for a direct or bank transfer.
When one of those patterns is found, the message is not delivered. The sender is asked to remove the private contact or off-platform payment detail and keep the conversation inside Nepal Will Do. The check runs on the server before attachments are stored, a message is created, or a live socket event is sent, so changing the website or app cannot bypass it.
A wallet balance is never adjusted without a matching ledger row being written first — that is the rule the wallet service is built around, so every credit and debit can be traced back to the order, refund, settlement or payout that caused it.
Separately, privileged staff actions — forcing an order state, deciding a dispute, reading a conversation, actioning a payout rail — are written to an append-only audit trail that application code only ever inserts into and reads from. The actor's email is stored alongside the reference, so the trail stays readable even if that account is later renamed or removed.
Dispute outcomes are recorded as events on a per-account trust ledger, and a derived score drives automatic consequences: an elevated rate of lost or refuted disputes attracts a payout delay and a cap on the order value the account can transact, and a pattern of refuted disputes means a staff pre-screen before a new dispute can even be opened.
Fraud is handled differently from everything else on that ledger. A confirmed fraud event suspends the account and alerts the operations channel — and that event has exactly one author: a staff member deciding it on the dispute desk. The automated dispute analysis can raise suspicion for a human to look at, and it can never by itself suspend anyone.
Payments, wallet movements, payout failures, reconciliation mismatches and manual transfers raise operational alerts, so a money event nobody expected is noticed rather than discovered in a database weeks later. Manual transfers carry the id of the administrator who initiated them.
What that is not: a reporting channel to any authority, and not a monitoring rule tuned to a regulatory threshold. It is an internal alert into a staff channel.
The data itself
A control that collects sensitive financial identifiers and then leaks them has made things worse. This is where those identifiers are allowed to appear.
| Who | What they see | Why |
|---|---|---|
| The owner | Their own full bank account number, but only through an explicit, deliberate reveal — not as a field on the session payload that every page load fetches. | A number carried in the session response would live in client memory for the whole visit and in every error report and network log that captured it. Fetching it once, on a click, keeps it out of all of those. |
| The payout desk | The full account number and the uploaded government ID, on a staff-only queue. | A human has to read the destination against the ID in order to send the money by hand. That is the entire purpose of the rail, so the desk is the one place the number is legitimately visible. |
| Everywhere else in the product | The last four digits only — **********0123. Payout phone numbers are masked to their first two and last two digits. | Account masking is deliberately stricter than phone masking: the leading digits of a Nepali account number encode the bank and the branch, so revealing a prefix narrows the search space in a way a phone prefix does not. |
| Logs and third-party channels | Nothing. No account number is written to a log line or sent to an operations chat, and a scrub on the way out masks any bare 9-to-24-digit run as a backstop even if a future call site tried to. | An operations chat is a third-party history with retention nobody here controls and a membership that changes. Submitting or editing a remittance rail deliberately writes no log line, no webhook and no audit row at all — each of those would be a second copy of the account number somewhere with different access rules. |
Uploaded government IDs are stored as the most restricted objects in the system, readable by the owning user and by staff, never public. Full detail on storage and retention is in the privacy policy.
The edges
A control described beyond its actual reach is worse than no description, because someone will rely on the difference.
If you think a payment on Nepal Will Do is not what it appears to be
Your wallet page lists every credit, debit and payout with the order it belongs to. Your earnings page shows each payout's timeline, including any hold and the reason for it.
The full money journey, the fee schedule, the payout rails and an honest account of timing.
The frozen scope contract, self-service settlement, and a written human verdict.
The marketplace relationship, account rules and the on-platform rule.
What is collected, who else receives it, and how uploaded documents are stored.
The hold window and withdrawal minimum on this page are read live from the platform's public configuration, so they always match what the system is enforcing. Every other statement here describes code in this repository as it stands on 25 July 2026 — and none of it is a claim of regulatory compliance.