How it protects a payout
Between "we owe this seller money" and "the money left", Pehmen inserts five checks, two of which need a person, one of which needs a different person, and all of which leave a record.
Written for risk and finance leads.
The path money takes
Each box is a record you can open in the dashboard. Nothing on this page is a description of good intentions; it is a description of what the software refuses.
1. The destination was registered, not typed
A payout goes to a beneficiary: a destination that was registered ahead of time, fingerprinted so the same account cannot be registered twice under different names, and checked with the provider for the account holder's name. The account number is never stored in Pehmen. A payout instruction names a beneficiary id, never a bank account.
2. The destination cannot be changed and paid in the same breath
If the seller's destination changed recently, the change itself went through the beneficiary change workflow:
- Cooling-off. The change waits 24 hours by default, 72 when the rules hold it. The window cannot be skipped.
- Both contacts are told. The old verified channel and the new one receive a notice. The change cannot advance until both notices are delivered. A hijacker who controls the new email still has to get past the old one.
- A second person approves. With a fresh two-factor code. Whoever requested the change cannot approve it.
- The account-takeover rule. Anyone who changed their own login credentials in the last 24 hours, including enrolling two-factor for the first time, can neither request nor approve a change. A takeover session cannot change both the credentials and the destination of money.
3. The rules decide first
Every payout instruction passes through the Gate when it is created. The published rules, yours, versioned, dual-approved, look at the seller's verification level, whether the destination is new or recently changed, how the amount compares to this seller's history, whether the order was fulfilled, whether a case is open, and answer with one of six words. ALLOW moves the instruction to approved. Anything else holds it with the reason codes attached, in plain words, for a person to read. There is no free text; every reason is one of sixty codes in a fixed registry.
4. Evidence of delivery can be required
A policy can require fulfilment evidence before release: a signed event from your own systems saying the tickets were issued or the goods shipped, at a tier the policy accepts. A payout that needs evidence and has none stays held with FULFILLMENT_EVIDENCE_MISSING. A delivery record that was later cancelled reverses the evidence.
5. Two people, two acts, two permissions
Approving a payout and releasing it are separate permissions, and both need a two-factor code verified in the last five minutes. Above the dual-control threshold the approval itself needs two different people. The approval is bound to the exact content that was reviewed; if anything about the instruction changes after approval, the approval is stale and refused. Release is the only call in the product that tells a provider to move money.
What an attacker has to defeat
- ChangeThe cooling-off window, both notices, a second approver, and the 24-hour credential rule.
- RulesA published policy that flags new or recently changed destinations, unusual amounts and unverified sellers, evaluated on every instruction.
- PeopleTwo permissions held by people who each have to produce a fresh second factor, and above the threshold, two different people.
- RecordAn append-only, hash-chained audit trail. Yesterday cannot be quietly rewritten to hide what was done.
What this does not protect
It does not stop a legitimate seller from being a bad actor with a legitimate account and a legitimate destination; only your verification and your rules do that. It does not protect the buyer's money in the provider's hands; the provider does. It does not decide for you; it enforces what you decided. The boundaries page is the full list.