Financial crime and anti-money laundering

Sellstamp is a payment facilitator, not a payment institution. We hold no client funds, operate no balance, execute no transfers and are not a party to any payment.

A merchant brings a payment account they already hold — Stripe, PayPal, Mollie, Monri, CoinGate, a bank rail. That provider onboarded them, ran the identity and business checks its own licence requires, monitors the flow of funds it actually handles, and files whatever its regulator requires it to file. Those are the anti-money-laundering controls protecting a transaction on this platform, and they are the provider’s.

This page has not been reviewed by a lawyer. It describes where the obligation sits in this arrangement and what this product actually does — it is not advice about your own regulatory position, and where it and the product disagree, the product is what is true.

Customer due diligence on merchants is therefore delegated rather than duplicated. That is a deliberate decision recorded in this codebase, and the onboarding copy a merchant reads says so at the point they connect a provider. We would rather state it than run a second, weaker identity check and imply it means something.

A policy that lists controls a company does not operate is worse than no policy, because somebody relies on it. So, explicitly:

• No customer due diligence programme of our own, no identity documents collected, no verification tiers and no beneficial-ownership register.
• No sanctions or politically-exposed-person screening. The provider holding the account runs that against the parties it actually pays.
• No transaction monitoring of payment flows, because no payment flow passes through this system to monitor.
• No nominated officer, no suspicious-activity reporting regime and no regulatory registration, because this product is not the regulated party in the arrangement.

If your situation requires a platform that is the merchant of record and carries those obligations itself, this is not that product, and it is better to know before you build on it.

Everything below exists in the product, is enforced in code, and is named individually so it can be checked rather than assumed.

• A day between a payout change and the money. Changing where an existing connection pays out pauses that connection for 24 hours — it takes no new payments and serves no account details in that window. Proving you knew a password a minute ago cannot distinguish a stolen session from its owner; a day is the window in which the alert already in the owner’s inbox can be acted on. A first-ever connection is never held, and the hold cannot be waived.
• A staff hold that only a person can lift. Separate from the timed one, and deliberately not a clock: it ends when a named staff member clears it with a typed reason, because “a human needs to look at this” is not something a timer can decide it has done.
• Automatic refusal of card-testing bursts. Fifteen checkouts from one browser or fifty from one network at one store in ten minutes. It is the only automatic refusal in the product, and it cools down the attacker rather than the shop.
• Cross-store correlation, read by staff. One device seen at four or more shops, or one network at six or more, inside three days. There is no button on those rows — acting on one means opening the store and using a tool that demands a typed reason.
• Merchant-set fulfilment holds. A merchant can hold delivery over an amount, or for devices their store has not taken a payment from. The payment still settles; the goods wait for them.
• A complete, attributable record. Every consequential act is audited with the person who took it and the reason they typed — suspensions, payout holds, key reveals, erasures, impersonation. That is what a lawful request gets answered from.

Because you are the seller and the account holder, the obligations that attach to that are yours.

• Meeting whatever your payment provider requires of you, and keeping that account in good standing.
• Selling only what you are lawfully permitted to sell, where you and your buyer are — the acceptable use policy sets out the categories that are out of bounds here regardless.
• Keeping the transaction records your own jurisdiction requires. Sellstamp produces the invoices and the reporting figures; filing anything is yours.
• Not using a store to move value that has nothing to do with a real sale. An invoice for goods that do not exist is not a grey area.

We will respond to a valid, properly served request from an authority with jurisdiction, and we will provide what we actually hold — order and invoice records, account and audit history, store content.

What we cannot provide is anything we never kept. Fraud signals are one-way hashes with no raw value stored anywhere; there is no location data in this product; and no card details exist in this system to produce.

A request about the movement of funds belongs to the payment provider that moved them, and we will say so rather than speculate from an order row.