Money moves between people who love each other.
We built it like it matters.

Verification (30 pts). Email confirmed, phone confirmed, government ID matched (where verified-payee status is sought), Stripe Connect KYC/KYB cleared. Optional for low-value flows; required to receive money above thresholds.

Payment history (25 pts). Volume sent and received, time-on-platform, chargeback ratio, dispute rate. A clean record over time compounds.

Reciprocity (20 pts). Not just received — also sent. Accounts that only ever receive money score lower than accounts that participate. Reciprocity is the strongest single antidote to one-way fraud.

Fraud flags (15 pts). Any signal that landed: card-testing pattern, mismatched geolocation, velocity spikes, prior platform suspension. Decays slowly with good behavior, never to zero on confirmed flags.

Account age (10 pts). Time-on-platform, with a logarithmic curve. New users start with reasonable trust; a five-year clean account is meaningfully different.

501(c)(3) lookup via IRS Form 990. Outcome funds routed to nonprofits hit a live IRS Form 990 lookup. The EIN is verified, status is checked, the nonprofit’s mission statement is matched against the fund’s stated purpose. A nonprofit that lost its 501(c)(3) status three months ago does not slip through — we re-check weekly.

What “verified payee” gets you. A green check on your profile. Earlier reserve release. Higher Trust Score. Eligibility for outcome funds, group buys above $1,000, and tax-PDF generation. It is the only way to receive money above $5,000 lifetime.

Every refund above $1,000, every PII release in response to a law-enforcement request, every account merge or deletion that touches money — requires two distinct Gish staff members with separate cryptographic keys to co-sign the operation. The audit log records both. No exceptions, including for the CEO.

This isn’t a policy. It’s enforced in code. The internal admin tool literally won’t execute a privileged action without two signatures. The second signer cannot be an automation; it has to be a different human approving from a different session. The transcript of the approval is appended to the audit log.

Why? Because the single biggest threat model for a consumer payments rail is not external attackers. It is internal abuse, social engineering of a single admin, or a coerced employee. The two-person rule defangs all three.

Security teams know the truth: most posture is bolted on. A startup ships a payments feature, a fraud incident teaches them a lesson, they hire a CISO, the CISO retrofits the architecture into something defensible. The result is functional but expensive — six-figure annual security spend, slow product cycles, the perpetual sense that the next 0-day will be the one that goes the wrong way.

We started the other way. Three architectural decisions were locked into the design before the first gift was ever sent, because we knew they could not be added later without rebuilding everything on top of them.

The booking vault is on-device by default. If we had stored passports and travel details on our servers in plaintext for the first six months and then tried to move them to a Secure Enclave model later, it would have taken an engineering year and a multi-month migration window during which old data would have lived in two states. Instead, the very first version of the experience-gift product wrote ciphertext to the server and held the key on the device. Today the model is the same model. There is no “legacy plaintext bucket” for an attacker to find.

The two-person rule is in the admin tool, not in policy. We could have written a policy that said “admins should ask each other to co-sign refunds above $1,000.” That policy would be ignored under pressure, social-engineered by a clever attacker, and slowly forgotten as the team grew. Instead, the admin tool refuses to execute the action without two distinct cryptographic signatures. The policy is the code, not a wiki page.

The k-anonymity floor is in the query layer, not in dashboards. We could have said “advertisers should only see cohorts of 50+.” Instead, the query layer that serves both internal analytics and advertiser inventory refuses to return a row if the population is below 50. The advertiser cannot send a different request to bypass it because the floor is in the database, not in the UI.

These three choices feel like small architecture decisions. They’re actually the difference between “security incident” being a quarterly fire drill and being a quarterly non-event.

Most companies publish a security page with an empty “Recent Incidents” section that says “no incidents to report.” That is either a lie or it’s a definition of “incident” so narrow it’s useless to the reader. We’re going to take a different approach. The status page at status.gishme.com lists every degradation, every partial outage, and every security-relevant event from the last 24 months. We classify them by severity (SEV1 through SEV5), publish post-mortems on SEV1 and SEV2 events within 30 days, and keep the historical record indefinitely.

If you’re doing diligence on us and you want the redacted internal post-mortem for any incident referenced on the status page, write to security@gishme.com. Under NDA, we’ll send you the full internal write-up: what happened, what failed, what we did, what changed in production, and what we’re doing differently. We will not pretend we’ve never had an incident. We will pretend we’ve handled the ones we’ve had well, because we have.