Legal · Money
Financial crime controls
Last updated 25 July 2026
The short version
NepalCanWork 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 NepalCanWork 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.
This is a description of how the platform works, not a compliance statement
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 NepalCanWork meets any particular obligation.
In plain terms, so there is no room for a generous reading — NepalCanWork 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 NepalCanWork 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.[REVIEW: whether a formal AML programme, a written policy and an appointed compliance officer are legally required of a Nepal-registered marketplace that holds client funds in escrow and settles through a licensed payment provider — and if so, under which authority and on what timeline]
This document is a working draft
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
One way in, and only two ways out
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.
In — through the gateway, to the platform
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.
Held — as escrow, not as a transfer
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.
Out — a payout, or a wallet withdrawal
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
Which party checks what, on which rail
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 verified on 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 NepalCanWork 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 | NepalCanWork 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 | NepalCanWork, 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. |
Stated precisely: what the payment provider does and does not do for us
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 NepalCanWork — and that is a genuine strength worth saying plainly, because it puts a regulated institution between us and the destination account.
What is not true, and is worth stating just as plainly: Hamro Pay does not perform NepalCanWork'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 NepalCanWork 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.
Clients are not verified at all
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.
[REVIEW: whether client-side due diligence is required at any order value or cumulative volume, and what form it would take]
The exit
What has to be true before money can leave
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.
The destination must be gateway-verified
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.
One payout destination, one account
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.
A changed destination waits 24 hours
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.
The remittance rail waits for a person
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.
Changing the account or the name resets the review
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.
Payout identity and login identity are kept apart
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
What the platform notices, and what it keeps
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.
Steering payment off the platform is detected
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.
Be clear about what happens next, because it is less than people assume: detection never blocks a message. The message is delivered. Both parties see an inline reminder that staying on the platform is what keeps escrow protection, and a flag with the categories that tripped is stored on the message and on the conversation, where staff and the dispute assistant can see that a conversation tried to leave. It is a record and a nudge, not a wall.
Two records that only ever grow
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.
Consequences are graduated, and mostly automatic
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.
Money events reach a person
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.[REVIEW: the escalation route for a suspected-fraud or suspicious-activity report — who a user or a staff member reports to, what the platform is obliged to do with the report, what it must record, and whether and to whom it must be escalated outside the company]
The data itself
How bank details and payout numbers are handled
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. |
Where ID documents live
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.
How long any of it is kept
[REVIEW: the retention period for financial records, payout destinations, wallet ledger entries, audit rows and uploaded identity documents — including any minimum a financial-records obligation would impose and the maximum data protection would allow, which are the two ends this has to be settled between]
The edges
What these controls do not do
A control described beyond its actual reach is worse than no description, because someone will rely on the difference.
No screening of any kind is performed
No transaction thresholds are monitored
Nothing off the platform is covered
If you think a payment on NepalCanWork is not what it appears to be
Every rupee has a row, and every row names its order.
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.
Escrow & refunds
The full money journey, the fee schedule, the payout rails and an honest account of timing.
Dispute & anti-scam policy
The frozen scope contract, self-service settlement, and a written human verdict.
Terms of service
The marketplace relationship, account rules and the on-platform rule.
Privacy policy
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.