Irreversible Actions — Payments & Marketplaces
Marketplace payouts and delistingsthat survive disputes months later.
No Stamp → No Ship for revenue-impacting actions.
Payout holds, delistings, and fraud/AML actions are income and reputational decisions — judged later by sellers, banks, auditors, and regulators after policy, tooling, and evidence have changed.
- Gate payout holds/releases and delistings by Status Link: not VALID → don't ship
- Reason-codes + scope that don't require exposing internal tools or raw data
- Refresh when evidence/policy/vendor signals change; WITHDRAWN stops reliance wherever checked
- Ships with two artefacts: Status Link (authoritative now) + Evidence Pack (decision-time snapshot)
Fail-closed•Append-only•Scope-bounded
Not a certification. Scope-limited verification. Acceptance depends on counterparty/programme requirements.
Why payments & marketplace buyers are moving now
Dispute pressure, vendor drift, and third-party scrutiny are converging.
Disputes become authority disputes
Sellers, banks, and partners challenge "what was authorised then — and is it still valid now?" Screenshot-driven review loops are expensive and fragile.
Policy and vendor drift silently invalidates approvals
Risk model retrains, PSP configuration changes, and threshold updates can silently invalidate prior hold/release decisions without anyone noticing.
Payout holds escalate to livelihood and legal pressure
Holds and delistings are income decisions. Delayed or unjustified enforcement triggers complaints, press scrutiny, and legal action.
Banks, PSPs, and schemes demand defensible evidence
Sponsor banks, acquirers, and scheme partners need verifiable records without internal dashboard access, NDAs, or portal logins.
Cross-border partners need portable proof
Multi-geography operations need evidence that travels without system integration — verifiable by link across jurisdictions and counterparties.
Revocation must propagate immediately
When a decision is withdrawn, every enforcement and payment point relying on it must see the change immediately — not after a manual sync.
Dispute reconstruction consumes engineering and legal time
Rebuilding what was true at decision time across risk tools, case management, and policy versions is slow, expensive, and error-prone.
Good Proof provides scope-limited verification evidence and stop-rely semantics. It is not a certification.
What a Stamp proves (and what it doesn't)
Proves (within lane scope)
- Decision class + outcome (hold/release/delist/reinstate/restrict)
- Decision/execution timestamp
- Signer/authority reference
- Scope boundaries + expiry window
- Validity state (VALID / NEEDS_REFRESH / WITHDRAWN / NOT_VERIFIED)
- Evidence window for disputes and audit
Does NOT prove
- Underlying truth of the allegation/claim
- Outcome correctness
- Fraud model correctness
- Raw PII or sensitive evidence by default
- Certification or regulatory compliance
In disputes: Status Link = reliance state now. IDA Evidence Pack = fileable snapshot for decision-time record.
Not a certification. Scope-limited verification. Acceptance depends on counterparty/programme requirements.
Why this lane exists
In payments marketplaces, disputes are authority and reliance disputes.
Evidence is fragmented across payment processors, risk tools, support tickets, and policy versions. Disputes arrive later under new rules; decision-time truth becomes unprovable.
The question is not "did it happen?" but "was it permitted in scope, under which policy/version, and is reliance still valid now?"
Good Proof converts fragmented records into a machine-checkable, contract-referenceable gate. External parties — sellers, banks, PSPs, auditors, regulators — demand defensible records without portal access or manual attestations.
Why now
Disputes + partner friction
Payout holds and delistings are challenged later — by sellers, banks, PSPs, and partners — after policy and tooling have changed. Portable decision-time proof reduces repeat reviews.
Governance + accountability expectations
Across EU, UK, US, Canada, Australia, and Asia hubs, marketplace and payments platforms are expected to govern high-impact automated decisions with accountable records and change control.
Third-party scrutiny
Sponsor banks, PSPs, acquirers, insurers, and auditors increasingly expect defensible records without portal access or manual attestations.
Good Proof doesn't certify compliance. It makes high-impact marketplace controls verifiable, refreshable, and withdrawable by link.
Global Coverage
Regulatory reality
No hype, no compliance claims — portable proof that survives cross-border review.
EU
Transparency, record-keeping, and accountability expectations for marketplace and platform decisions; defensible 'reasons' reduce disputes.
UK
Risk assessment and record-keeping pressures; escalating scrutiny for harmful or unfair marketplace outcomes.
US
Procurement, banking/PSP partners, and governance frameworks drive accountability expectations for high-impact actions.
Canada
Rising expectations for safety, transparency, and defensible records across platform commerce.
Australia
Strong online safety and consumer protection attention; dispute-ready records reduce escalation friction.
Asia
AI and governance frameworks emphasize bounded risk, traceability, and controllability across payment platforms.
Middle East
Financial services governance expanding; defensible records for marketplace and payment decisions across jurisdictions.
Africa
Fintech and mobile-money governance strengthening; portable verification supports cross-border reliance and partner scrutiny.
Good Proof doesn't certify compliance. It makes high-impact marketplace controls verifiable, refreshable, and withdrawable by link.
Jurisdictional Configuration
Country overlays can be configured per programme
Scope boundaries
Evidence windows
Redaction matrix
Verifier checklist
Disclosure/retention/appeal handling
Language support + verifier-access requirements
Examples include programme-specific mapping for UAE, Saudi Arabia, South Africa, Kenya, Nigeria, and other jurisdictions where requirements differ.
Not legal advice. Final legal mapping is owned by programme counsel.
What gets stamped in this lane
High-impact action classes (examples—define per programme):
Payouts & Enforcement
- Payout hold/release decisions
- Seller delistings/restrictions/reinstatements
- Seller suspensions blocking earning
- Fraud holds and risk flags affecting payouts
Compliance & Appeals
- KYC/AML/sanctions-related holds/escalations (scope-bound)
- Chargeback reserve actions with merchant disputes
- High-risk overrides (limit/velocity exceptions, risk tool overrides)
- Appeal outcomes and final review closures
If a decision can be challenged by a seller, partner, bank, PSP, regulator, or court, it belongs in a stamped lane.
PDFs are great for filing. Status Links keep them current.
Integration in 3 touchpoints
1
Issue
At payout hold/release, delist/restrict, seller suspension, or high-risk override → require a Stamp.
2
Notify
In seller notices, partner/PSP escalations, dispute tickets, and audit trails → include the Status Link.
3
Rely
At funds movement/release, continued restriction, reinstatement, or settlement/dispute closure → verify Status Link (fail-closed).
High-impact gating only. Everything else runs normally.
If it gets challenged, does it survive?
PDFs are great for filing. Status Links keep them current. Counterparties need a link they can check today.
VALID
Decision is currently valid within scope. Not guaranteed correctness.
NEEDS REFRESH
Policy/model/tool surface changed → re-verify before rely.
WITHDRAWN
Stop-rely immediately. Revocation returned wherever Status Link is checked.
NOT VERIFIED
No proof exists or verification can't be performed. Block or escalate.
If it's not VALID, the action does not execute.
Fail-closed: unreachable verification returns NOT_VERIFIED.
Block or escalate, never assume validity.
VALID means valid within scope, not guaranteed correctness.
When status changes — and what it means
Status triggers define when a Status Link moves to NEEDS_REFRESH or WITHDRAWN. Understanding these ensures fail-closed enforcement at verification time.
NEEDS_REFRESH
When any of these occur, re-verify before you rely.
Risk model/rule pack version change
Threshold changes (velocity/amount/category/geo)
Settlement/release condition changes
PSP/processor/rail configuration changes
KYC/KYB/sanctions vendor or policy changes
Scheme/sponsor-bank requirement updates
New evidence or merchant posture changes
Evidence window expiry
NEEDS_REFRESH means "re-verify before you rely," not "defer."
WITHDRAWN
Stop-rely signal. Execution must not proceed.
Confirmed fraud/abuse invalidating prior decision
System integrity or misconfiguration incident
Sanctions/compliance breach discovered post-approval
Wrong policy version applied to decision
Material incident requiring stop-rely pending investigation
Legal/regulatory stop-order (programme-scoped)
Fail-closed: Wherever the Status Link is checked, if WITHDRAWN → block or escalate.
Multi-vendor control surface
The Stamp scope covers the full decision surface across your vendor stack. Material change in any component → NEEDS_REFRESH.
Risk engine
Model version, rule pack, threshold set, scoring config
PSP / Acquirer
Processor routing, settlement terms, scheme rules
Case management
Workflow version, escalation rules, SLA config
Policy engine
Rule pack version, velocity limits, geo restrictions
Payout orchestration
Release conditions, reserve rules, corridor config
KYC/KYB/Sanctions vendor
Screening vendor, watchlist version, match thresholds
Surface change → NEEDS_REFRESH. Integrity compromise → WITHDRAWN.
What you get (two artefacts, one standard)
Status Link (authoritative now)
A counterparty-verifiable link that returns current validity within scope.
- Returns: status, scope, expiry, verified_at, signer, verify_url
- Fail-closed: unreachable = NOT_VERIFIED
- Built for contracts, runbooks, tickets, and automated gates
IDA Evidence Pack (snapshot then)
View full details →A time-stamped snapshot you can forward, file, and cite.
- Built for disputes, audits, and procurement reviews
- Minimal disclosure by default (proof ≠ payloads)
- Append-only history; withdrawal ≠ erasure
PDFs are great for filing. Status Links keep them current.
What's inside the IDA Evidence Pack
Decision-time snapshot for disputes, audit, and filing.
Decision summary + lane scope boundary
Decision-time timestamp + evidence window
Policy/tool surface identifiers + version references
Reason-code + authority reference
Vendor signal references as identifiers (not raw payloads by default)
Verification transcript + timestamps
Redaction matrix (what is intentionally excluded)
Minimal disclosure by default. Programme-scoped if required, with auditable access trails.
What counterparties can verify
No login. No portal. Just a link that fails closed.
Live validity state: VALID / NEEDS_REFRESH / WITHDRAWN / NOT_VERIFIED
Scope boundaries and expiry window
Signer authority reference (system or Guardian panel)
Verified_at timestamp
Forwardable IDA Evidence Pack
Optional signed verify responses (programme-scoped)
Optional: tamper-evident anchoring to Good Proof LIVE Ledger for high-assurance programmes.
Who uses this in Payments & Marketplaces
Buyer roles with high-impact decision accountability.
Risk Ops (Marketplace/PayFac)
Pain: Payout holds and terminations escalate with no portable proof trail.
Outcome: Every high-impact decision has a verifiable Status Link a counterparty can check today.
Book a Payments Stamp SprintPayouts / Seller Ops
Pain: Holds freeze livelihoods; you need a defendable route without opening internal systems.
Outcome: Live status + scope boundaries make decisions appealable without oversharing.
Book a Payments Stamp SprintLegal / Compliance
Pain: Disputes turn into discovery; PDFs don't prove what was true at decision time.
Outcome: Evidence Pack is time-stamped; Status Link remains authoritative for current validity.
Book a Payments Stamp SprintTrust & Safety / Marketplace Integrity
Pain: Enforcement decisions are challenged after policy and tooling have changed.
Outcome: Machine-checkable gate with refresh/withdraw triggers tied to policy version changes.
Book a Payments Stamp SprintProcurement / Vendor Risk
Pain: PSP and risk vendor changes require rework across contracts and audit evidence.
Outcome: Vendor surface changes trigger NEEDS_REFRESH; procurement clause template ready for legal review.
Book a Payments Stamp SprintExternal verifiers (banks, PSPs, acquirers, auditors)
Pain: Verification requires accounts, portals, NDAs, or manual attestations.
Outcome: Verify by link: scope, expiry, signer, and status — no login, no portal, minimal disclosure.
Book a Payments Stamp SprintWhere budget comes from
Usually funded from existing risk, disputes, and compliance lines — not new category spend.
Disputes / chargeback operations
Trigger: Rising dispute volume, seller complaints, or partner escalation friction
Why it fits: Portable decision-time proof reduces repeat reviews and reconstruction effort.
Risk governance / fraud controls
Trigger: Model retrain challenge, threshold dispute, or vendor change audit
Why it fits: Status triggers make policy/vendor changes machine-checkable, not meeting-checkable.
Payout operations / seller support
Trigger: Payout hold complaints, livelihood escalation, or regulatory inquiry
Why it fits: Live Status Link gives sellers and partners verifiable state without internal system access.
Legal defensibility / complaints handling
Trigger: Seller litigation, press scrutiny, or ombudsman inquiry
Why it fits: IDA Evidence Pack is the fileable snapshot for decision-time record in disputes.
Procurement / vendor assurance
Trigger: PSP change, risk tool migration, or acquirer onboarding
Why it fits: Contract-ready clause template + Schedule A with status-linked operating rules.
Audit readiness / partner assurance
Trigger: Sponsor-bank review, scheme audit, or insurer evidence request
Why it fits: Counterparty verification by link; no portal access or manual attestation required.
Sponsor-bank / compliance programme
Trigger: Scheme requirement change, AML review, or sanctions screening audit
Why it fits: Scope-bounded verification with withdrawal propagation and fail-closed defaults.
Start with one high-impact lane and prove dispute-handling friction reduction before expansion.
Procurement-ready clause
Template language for your legal team.
"For any defined high-impact payout, restriction, or enforcement action, Provider shall obtain and maintain a Good Proof Stamp with an active Status Link. Actions taken with a status of NOT_VERIFIED, NEEDS_REFRESH, or WITHDRAWN shall be treated as unverified and must be blocked or escalated per programme rules."
Schedule A (template — programme terms)
Definitions + operating rules procurement teams can copy/paste.
1. Definitions
- High-Impact Action Class: the defined action lane (e.g., payout hold, seller suspension, fraud flag) requiring verification.
- Status Link: the verification endpoint returning validity state + scope boundaries.
- Scope Boundary: the policy/tool/processor configuration covered by the Stamp.
- Evidence Window: the programme-defined period and inputs considered for decision-time verification.
- Evidence Pack: the fileable, programme-configured snapshot for disputes/audit/procurement.
2. Required states
- VALID→ may proceed within scope.
- NEEDS_REFRESH/ NOT_VERIFIED / WITHDRAWN → must block or escalate per lane rules.
- Fail-closed:timeout/unreachable ⇒ NOT_VERIFIED.
3. Withdrawal / stop-rely semantics
- WITHDRAWN is returned wherever the Status Link is checked.
- No execution may proceed on WITHDRAWN.
- Optional: programme hooks/notifications for stop-rely distribution.
4. SLAs (placeholders — programme-defined)
Verifier availability target: [___]%. Response-time target: [___] ms. Support turnaround: [___] hours.
5. Evidence retention defaults
Evidence Packs retained per client retention policy and applicable jurisdiction/programme needs.
6. Verification transport/security requirements
- HTTPS-only verifier; TLS required, no insecure overrides
- verify_url host MUST match official verifier allowlist
- Redirects forbidden; timeout/unreachable ⇒ NOT_VERIFIED
Not legal advice. Template language for your legal team.
OUR MOAT
We Care Defensibly
A Global Human Layer
Our Mind Chill Guardian Story
A global human layer that software can't fake.
When liability lands on a person, the sign-off should too.
Conflict-checked · Rotation-based · Audit-traceable · Programme-scoped
When Guardians are used (only when required)
Most decisions remain automated. Humans step in only where human finality is required: exception approvals, disputes, high-risk overrides, or post-incident outcomes with human liability.
Mind Chill Guardians provide programme-scoped human finality for exception lanes only, minimizing sensitive payload handling, with anti-rubber-stamp controls: conflict checks, rotation, sampling audits, and multi-review thresholds for high-risk lanes.
From calming minds to defending outcomes
Mind Chill began in 2017 as immersive art built to reduce anxiety and create calm at scale. Then the same feeds that buried calm and rewarded outrage started training the systems that now make real decisions. We didn't want more rhetoric. We wanted receipts.
The moment it clicked
A message arrived: someone's child felt safer because of what they experienced. Around the same time, lived experience inside our own community made one thing obvious: the nuance that matters in high-impact decisions can't be reliably reduced to a prompt. So we designed a human layer for the edge cases—structured, scope-bound, and auditable.
Guardians are not a "panel." They're a network.
Mind Chill Guardians come from different countries, backgrounds, and lived realities. That diversity is not branding—it's risk reduction. It makes decisions harder to game, easier to challenge, and more credible under scrutiny. Guardians do not "run the system." They review only what the lane requires humans to own.
Receipts over rhetoric
Operational Guardians plug into Good Proof lanes as a controlled finality mechanism: conflict checks, rotation, multi-review where required, and an audit trace tied to a Status Link. Minimal disclosure by default. If a decision is appealed months later, you can show what happened, within scope, without dumping sensitive payloads.
Why buyers choose Guardians
Lived experience at the edge cases (not a generic helpdesk)
Conflict-checked + rotation-based (anti-rubber-stamp by design)
Multi-review on high-risk lanes (when the programme requires it)
Audit-traceable outcomes (defensible in disputes, audits, procurement)
Minimal disclosure by default (proof, not payloads)
What you get in 30 days
One decision class, production-ready controls.
One high-impact decision class defined (scope + evidence window)
Stamp issuance workflow integrated (staging or production)
Status Link verification route tested with counterparties
Refresh and withdrawal triggers configured
One redacted IDA Evidence Pack specimen generated
Dispute-ready verifier checklist + clause language draft for legal review
Go/no-go rollout recommendation
Due Diligence FAQs
Make marketplace decisions shippable.
Start with one decision class. Prove it works. Expand when counterparties rely on the Status Link.
Not a certification. Scope-limited verification. Acceptance depends on counterparty/programme requirements.