Identity verification
Three partners, one onboarding flow. The question technical buyers ask most is "who actually holds the identity data?" This page answers it, including the parts that aren't built yet.
SorenPay is in private beta and every workspace runs in sandbox. In sandbox no real identity check is made unless our partners' test environments are connected, and nothing here moves real money.
Who checks what
| Check | Who | When | What they get |
|---|---|---|---|
| Business verification (KYB) | Our banking partner | You submit the business form during onboarding | Legal name, EIN, country and date of formation, business type, website |
| The business's owners | Our banking partner | Same form | Each owner's name, date of birth and share of the business |
| People who get cards | Our card issuing partner | When you add a cardholder (POST /api/cardholders) | Name, email, phone and address, linked to your business |
| Personal accounts | Our identity-verification partner | "Start identity check" in personal onboarding | A photo ID and a selfie, collected on the partner's own page |
| Sanctions screening | Our banking partner, as part of business verification | At onboarding | Done on the partner's side |
| Sanctions screening by SorenPay | SorenPay | When a recipient, workspace, business owner, member, personal account or cardholder is added, and again every night | Names, countries and addresses, checked against OFAC's SDN and Consolidated lists |
| Crypto Travel Rule | Not built yet |
In sandbox:
- Business verification goes to the banking partner's test environment
when it's connected. A legal name of
Reviewreturns "in review",Deniedreturns "denied", anything else is approved. Without a connection, the form is only saved. A sandbox approval doesn't carry over to live: before real money moves, you verify the business again, and the status in Settings goes back to "not started" until you do. - Cardholders are saved but not sent to the card issuing partner, and stay
pending. - Personal accounts show a test page where you choose whether the check passes or fails.
Sanctions screening
Our banking partner screens a business and its owners as part of business verification. On top of that, SorenPay screens against OFAC's SDN and Consolidated (non-SDN) lists itself:
- When something is added: a recipient, a workspace and its first member, a personal account, the business and every owner in a business verification, a cardholder. A close match pauses that step before anything reaches our banking or card issuing partner.
- Every night: everyone already on the platform is checked again against the current list. A new match freezes the affected party: payments to that recipient, or the whole account (cards frozen, payments paused).
- Countries and regions: we don't send payments to, or open accounts for, people or businesses in Cuba, Iran, North Korea or Syria, or in the Crimea, Donetsk or Luhansk regions of Ukraine.
Our compliance team reviews every match and either clears it or confirms
it. When a match is cleared, payments work again. Cards paused by the review
stay paused until you turn each one back on in the dashboard (or with
PATCH /api/cards/{id}). Names are compared after normalizing spelling,
accents, word order, look-alike characters and words that are split, joined
or broken up with punctuation, so unusual spellings don't slip through.
If the list can't be loaded, screening refuses new recipients rather than
letting them through. What you see is a plain "We need to review this
recipient before you can pay them."
In sandbox, screening uses a small test list, not the official one.
Travel Rule
The Travel Rule requires originator and beneficiary information to travel with
crypto transfers of $3,000 or more. SorenPay doesn't exchange that information
yet, so USDC withdrawals of $3,000 or more are refused with
422 travel_rule_unsupported ("Withdrawals of $3,000 or more aren't available
yet."). Smaller withdrawals work in sandbox.
What SorenPay stores
We store:
- What you type into the business form: the business details, and for each owner their name, date of birth, address, share of the business and, if given, the last 4 digits of their SSN.
- What you send for a cardholder: name, kind, email, and, if given, date of birth, last 4 digits of their SSN and a shipping address. The API never returns the date of birth or SSN digits.
- Partner references and decisions: the partner's case or check ID, and the outcome (approved, in review, declined).
We never collect full SSNs. We never see or store photo IDs or selfies: the identity-verification partner collects them on its own page. We never store full card numbers.
Data retention
We don't delete regulated records (ledger, verification decisions). The periods below are how long we keep them at least.
| Data | Where | Kept for at least |
|---|---|---|
| Business verification details and decision | SorenPay database | 7 years (Bank Secrecy Act) |
| Ledger entries | SorenPay database | 7 years (Bank Secrecy Act) |
| Photo IDs and selfies | Identity-verification partner | The partner's own policy |
| Business verification records at the bank | Banking partner | The bank's own policy |
| Full card numbers | Never stored |
Access and deletion requests
GDPR / CCPA: email privacy@sorenpay.com with the email address or workspace ID. We collect what we hold and ask each partner for theirs.
Regulated records (ledger, verification decisions) can't be deleted during the retention period. Other personal data can.
Audit trail
Payouts, ledger corrections and transfers we pick up from the bank are written to a hash-chained audit table, so a changed or deleted row breaks the chain. Verification decisions are recorded on the business or personal account, but aren't in the hash-chained table yet. Sanctions screening decisions, freezes and compliance reviews are kept in a separate append-only compliance log.
Related
- Compliance overview
- Cards: what's built for cards today
- Disputes + chargebacks