Principle 1
No custody
PayeeProof does not store, hold, or control user funds. It exists to return a control record, not to become part of transaction custody.
Security & operating model
PayeeProof is built to control payout and treasury risk without becoming a new trust problem.
PayeeProof is a non-custodial control layer for modern financial operations. It verifies transfer details before approval and analyzes completed transactions after a mistake, while fund movement, policy, and final approval remain with the operator. It also supports AI-assisted finance workflows without taking custody or executing transfers.
No custody
No fund movement
Live chain checks
Protected access
Event delivery
Verification records
Security posture
What a reviewer should understand first
CONTROL LAYER
No custody. PayeeProof does not hold customer funds and does not ask for private keys or seed phrases.
No execution. The service verifies or analyzes; the payout owner still decides whether funds move.
Live lookups. Results rely on live blockchain reads and structured rules, not on surface-level form validation alone.
Explainable results. Outputs are built as clear records with verdict, reference, confidence, destination class, and next action.
Scoped product. PayeeProof is focused on payout risk control. It is not a custody provider, wallet, exchange, sanctions engine, or full fraud suite.
Core principles
Security starts with clear boundaries, readable decisions, and no custody.
The safest version of this product is simple: verify before approval, block mismatches, explain the risk context, and leave final execution with the payout owner.
Principle 2
Block on mismatch
When network, asset, address, memo, or destination context does not look safe, the correct answer is to stop, reverify, or escalate — not to guess.
Principle 3
Explain the answer
A useful control should return one clear language: verdict, reference, confidence score, risk level, AI risk context, destination class, and the next recommended step.
Controls
What supports the current risk-control posture.
Access & request handling
Protected API access
AUTH
Protected access is used for protected integration endpoints.
Rate limits and anti-abuse controls reduce misuse, spam, and noisy automation against public and pilot flows.
Origin and policy checks can be used where browser-based access needs to stay restricted to approved surfaces.
Integrity & traceability
Operational records
RECORDS
Verification records create a reviewable output instead of an ephemeral chatbot-style answer.
Request identifiers and event records support tracing, support handling, and audit review.
Structured outputs are designed to fit ops logs, support workflows, and approval checkpoints.
External delivery
Webhook model
WEBHOOKS
Webhook signing helps receivers verify that event deliveries came from PayeeProof.
Delivery tracking makes it easier to confirm whether an event was sent and acknowledged.
Retry-aware handling supports operational reliability for downstream receivers.
Network analysis
Live checks
CHAIN
Live blockchain reads help classify a destination and review transaction state in real time.
Pre-send checks compare expected versus provided route details before approval, including risk context for fast-moving operations.
Recovery guidance anchors post-error analysis to a real transaction instead of generic advice.
Data handling
What PayeeProof needs — and what it should never need.
Typical data used by the service
Network, asset, address, memo or tag, and other transfer-route details submitted for a check.
Transaction hashes and intended-destination context for recovery analysis.
Verification records, delivery events, and operational metadata used to support service integrity and reviewability.
Pilot request details submitted through the contact flow.
Data PayeeProof should not require
Private keys
Seed phrases or wallet recovery phrases
Direct control over a user wallet
Authority to execute a payout on behalf of the operator
Boundaries
What PayeeProof is not.
Out of scope
This is not a custody or execution product
BOUNDARY
Not a wallet
Not an exchange
Not a payment processor
Not a sanctions, KYC, or full fraud platform
Not a guarantee that any post-error recovery will succeed
Operator responsibility
The payout owner remains in control
OPS
Final approval and execution remain with the operator.
Internal payout policy, exceptions, and escalation paths remain with the team using the service.
Unsupported or ambiguous cases should be reverified or escalated rather than forced into an automatic approval path.
FAQ
Short answers to the security questions teams usually ask first.
Does PayeeProof move funds?
No. It verifies or analyzes transfer details. Fund movement stays with the operator or the payout platform.
Does PayeeProof need private keys?
No. The service should never require private keys, seed phrases, or wallet recovery phrases.
Can PayeeProof replace payout policy?
No. It supports decision-making with structured outputs, but internal approval logic, exception handling, and AI automation policy remain with the team.
Where should security questions be sent?
Use hello@payeeproof.com for security questions, pilot discussions, or disclosure-related contact.