Proposed Fraud & Sanctions Policy
Current account deletion uses a 30-day recovery period with a displayed cancellation deadline. Keep backups is default; only explicitly reviewed eligible snapshots are included if chosen. Shared company records, other backups and external copies remain. See the current Privacy Notice for the operative scope.
1. Nature of the service
Circles AI is contact-management and AI-assisted business software. It is not presented as a bank, payment institution, money transmitter, remittance service, exchange, investment service, cryptocurrency issuer or customer-funds custodian. Current access is Free; paid checkout and credit purchases are disabled. No active card-payment adapter or verified-payment fulfillment flow is represented as available.
Proposed subscriptions buy software access. Proposed AI Circles buy eligible AI-service consumption within Circles AI; they are not model tokens, cryptocurrency or a cash wallet. Purchased units are nontransferable, do not expire merely with time, and have no trading, peer-to-peer transfer or cash-withdrawal function. A mandatory or promised refund of the original purchase is different from a withdrawal facility.
2. Scope of anti-abuse commitments
We seek to prevent the service from being used for fraud, unauthorized access, unlawful communications, sanctions evasion or other illegal conduct. The controls must be proportionate to the software's risks and applicable legal duties. A business named in the CRM is not automatically a customer of Circles AI, and imported contact data is not a completed identity-verification record.
Current technical controls include account verification/authentication mechanisms, limited privileged access, business membership scopes, usage limits, protected credentials and audit records for sensitive server actions. These controls are not a representation that every user has passed government-ID checks, screening, source-of-funds review or ongoing transaction monitoring. Automated sanctions/PEP screening and a regulated suspicious-activity reporting program are not claimed to be implemented.
Where a payment provider requires merchant verification, the operator must supply accurate legal-entity, beneficial-owner, business, bank and product information through that provider's authorized process. The provider independently decides eligibility. Publishing this policy does not guarantee acceptance by a bank, gateway, card network, app store or regulator.
3. Prohibited use and applicable restrictions
Users must not use false identity or stolen payment information, conceal an unauthorized account holder, evade access or usage restrictions, launder proceeds through the service, submit fraudulent refunds/disputes, or facilitate unlawful activity. Do not obtain credits with stolen funds, transfer them between people or represent them as an investment or exchangeable currency.
Access and transactions must comply with sanctions, export controls and other restrictions that legally apply to the operator, the transaction, the user or a service provider. Restrictions can depend on location, ownership/control, counterparties, goods/services and applicable licenses. We do not claim that every country's rules apply identically to every user, or that a nationality alone proves a prohibited transaction.
4. Risk review and verification
If there is a credible risk indicator, we may pause the affected service or prospective order while we verify authority and facts, as law and contract permit. Relevant indicators may include account takeover, inconsistent account/payment ownership, repeated failed or duplicate payments, attempts to circumvent limits, impossible usage patterns, or a legally relevant sanctions match. A signal is not a finding of wrongdoing.
Request only information necessary for the specific risk and permitted by law. Use secure submission and restrict access. Do not ask users to email full card numbers, CVVs, passwords, API keys or recovery codes. Do not collect identity documents from every Free user merely to imitate a financial institution's KYC process. Establish a justified verification workflow and retention period before collecting extra identity evidence.
5. Future payments, refunds and records
Before payments are enabled, the operator must establish provider-approved payment acceptance, transaction authentication where required, idempotent fulfillment, reconciliation, dispute handling and fraud controls. A browser success screen is not proof of payment. Store only the necessary provider identifiers and payment metadata; use the provider's permitted card collection flow.
An internal service-credit adjustment is not a refund by a bank, card network or AI provider. Unknown provider usage must remain visibly reserved pending reconciliation rather than being described as a completed zero-cost request. A refund must follow the Billing Policy and mandatory law. A suspicion alone does not authorize confiscating all value. If law requires a block or prohibits a refund, follow the applicable legal procedure, record the basis and reassess when the restriction changes.
6. Governance before paid activation
The operator must approve a risk assessment covering product features, customers, distribution, markets, suppliers and payment flows; assign an accountable person; train relevant staff; test the controls; and periodically review incidents and changes. A proportionate sanctions program should address management responsibility, risk assessment, internal controls, testing and training where applicable. The internal merchant checklist records the missing implementation and evidence items.
This policy must reflect actual operations. Until responsibilities, market scope and payment controls are confirmed, it is a review document and must not be advertised as proof of completed AML/KYC compliance. Report a suspected misuse at the contact above, with only the necessary details. Emergency or imminent-danger reports should go to the appropriate local authorities.