AML & sanctions policy

1. Policy Statement

Plan Our Reunion is an event collaboration platform operated by WeeBie Media, LLC, based in Tampa, Florida. We use the Reunion Fund name for payments and funding. "Plan Our Reunion", "Reunion Fund", "we" and "us" all refer to WeeBie Media, LLC, as section 1 of our Terms of Service sets out.

We are not a bank, a money transmitter, or a financial institution, and we do not hold customer funds. Payments on the platform are processed by Stripe, Inc., a licensed payment processor that runs its own identity verification, sanctions screening and regulatory reporting for the connected accounts and payments it handles. This policy describes what we do ourselves, what we rely on Stripe to do, and how the two fit together. It does not claim a program we do not run.

As a company based in the United States we comply with the sanctions programs administered by the Office of Foreign Assets Control (OFAC). We will not knowingly provide service to a person, or in a place, where sanctions prohibit it, and we will not knowingly let the platform be used to launder money, finance terrorism, or commit fraud.

2. Scope

This policy applies to everyone who uses the platform, to every event that enables contributions, to every subscription, to our staff and contractors, and to the service providers we rely on for payments. Where this policy and the Terms of Service differ, the Terms govern.

3. How Money Moves

• Subscriptions are billed by Reunion Fund through Stripe. Card details never touch our servers (Terms, section 3).
• Event contributions are charged directly to the organiser's connected Stripe account. The organiser, not Reunion Fund, is the merchant of record, and contributions settle into the organiser's own Stripe account. We collect a 1% platform fee through Stripe as an application fee (Terms, section 8).
• We never hold contributed funds as a balance for later disbursement. Because the money is never ours, we cannot move, freeze or disburse it ourselves. Stripe can, under its own compliance program.

4. Identity Verification

An organiser who wants to collect contributions must first complete Stripe Connect onboarding. Stripe collects and verifies the identity information its rules require, which can include legal name, date of birth, address and a government identity document, and Stripe decides whether the account may accept charges and receive payouts.

We do not collect or store government identification. We keep only the outcome: a verification status for the organiser's account and Stripe's report of whether the connected account can accept charges and receive payouts. The payout flow reads that status before any funds are released, and an organiser whose account is not enabled cannot collect or release contributions on the platform.

Contributors are not identity-verified by us beyond the checks Stripe applies to a card payment.

5. Sanctions

Stripe screens connected accounts and payment activity against the sanctions lists that apply to it, and can hold, restrict or close an account on that basis. We honour those decisions: a connected account that Stripe has restricted cannot accept charges or receive payouts through the platform.

We do not run our own sanctions screening. If we learn of a confirmed match from Stripe, a regulator or law enforcement, we suspend the account under section 2 of the Terms and cooperate with any lawful request that follows.

6. Platform Controls

These are the controls the platform itself enforces on money that moves through it.

• Committee approval. Where an event uses a committee, releasing collected funds requires approval from at least two committee members, and at least one of those approvals must come from a member who is neither the person requesting the release nor the organiser who receives it. The number of approvals required never falls below half of the members eligible to vote, and an organiser can set it higher.
• Records of every step. Payout requests, votes and refunds issued through the platform are written to an audit log with the acting account and the time. A contribution is recorded on the contribution itself with the contributor and the time, and a release is recorded on the payout request and on the Stripe payout with the organiser who released it. None of these records can be edited from the product, and the audit log has no delete path.
• Money records survive deletion. When an account is deleted, its money records are kept in anonymised form rather than removed, so a history of who paid what to which event cannot be erased by closing the account.
• Suspension. We may suspend or terminate an account for suspected fraud or abuse, and the acceptable-use rules forbid using the platform for any unlawful purpose.

7. Suspicious Activity

7.1 What we treat as a warning sign

• Money activity that does not fit the event's stated purpose
• Repeated refund or chargeback patterns on one organiser or one contributor
• Attempts to route contributions or releases around the committee rules above
• Reports from guests, contributors or committee members

7.2 What we do

When one of these comes to our attention, we review the account and the event, and we may restrict or suspend either while we do. We escalate to Stripe and give it the information it needs. We are not a bank or a money services business and have no independent reporting obligation of our own; where the law requires a report about a payment, Stripe, as the payment processor, makes it. We cooperate with lawful requests from law enforcement and regulators.

7.3 How to report a concern

Email support@reunionfund.com with a link to the event and a description of what you saw. We do not tell the reported account who raised the concern unless the law requires it.

8. Records

Money records (contributions, refunds, payout requests, approvals and releases) and the audit log are kept for as long as the event's money history needs them, and they are never removed by closing an account: once the account they belong to is deleted they are kept in anonymised form. They are encrypted in transit, stored with providers that encrypt at rest, and access to them is limited by role. What we keep about you more generally, and for how long, is described in our Privacy Policy.

9. Policy Review

We review this policy at least once a year, and sooner when the platform, our payment arrangements or the law change. The version and effective date shown above come from a single set of constants, and every material change is recorded in the changelog below.

10. Definitions

• Connected account: the Stripe account an organiser opens through Stripe Connect onboarding, into which contributions settle.
• Merchant of record: the party a contributor is paying and who is responsible for the charge, its refunds, chargebacks and taxes. For contributions that is the organiser.
• Sanctions: government restrictions, such as those administered by OFAC, on dealing with listed persons, entities or countries.

Further terms are explained in the AML glossary.

Changelog

• v2.1.0 (2026-09-22): Rewritten to describe the program we actually run. The previous text, carried over from an internal template, described a customer identification program collecting government identification from all customers, in-house sanctions screening, behavioural transaction monitoring and suspicious activity reporting to FinCEN, none of which this platform performs, and it contained placeholder links to internal forms that did not exist. The policy now states that identity verification and sanctions screening of connected accounts are performed by Stripe, that we hold no funds, which controls the platform itself enforces on releasing event funds, how to report a concern, and what we retain. This is a material change to how we describe our obligations; it does not change your rights.
• v2.0.1 (2026-09-21): Product renamed to Plan Our Reunion. Section 2.1 now says "events" where it said "campaigns". No change to your rights or our obligations.
• v2.0.0 (2026-06-13): Initial structured publication of AML & Sanctions Policy (extracted from comprehensive internal policy; added version metadata, JSON-LD, standardized layout).