Fintech is the vertical where analytics and compliance collide hardest. The events that matter most to the business — KYC approvals, first transactions, dispute rates — are also the events most likely to carry regulated data. A payload designed for product analytics becomes a compliance incident the moment a passport number ends up in the warehouse.
This reference covers the twelve events that span the fintech user journey, what each payload must contain, and the strict separation between analytics events and personally identifiable information. The focus is on neobanks, payment apps, and SME fintech — the schema generalizes to lending and investing platforms with minor additions.
The Four Stages of the Fintech Journey
Fintech funnels are fundamentally different from SaaS or ecommerce: users exist in your system long before they can use the product. KYC is the activation blocker, and its drop-off frequently exceeds 40% — more than signup, onboarding, and checkout combined in other verticals.
Stage 1 — Onboarding Events
signup_started
Fires when a user submits the first signup form (email + password, or phone number for OTP-based flows). Required parameters:
user_id— opaque, generated at signupacquisition_channel— organic / paid / referral / directcountry_of_residence— ISO 3166-1 alpha-2, used for regulatory routingdevice_type— mobile / desktop / tabletapp_version— for mobile apps, helps correlate with feature rollouts
signup_completed
Fires when the initial account creation succeeds (email or phone verified, password set). Precedes KYC.
email_verified / phone_verified
Separate events because they often happen at different points — and failure patterns differ. Include verification_attempts and time_to_verify_seconds.
Stage 2 — KYC Events
kyc_started
Fires when the user begins identity verification — uploads the first document, takes a selfie, or consents to data sharing with the KYC provider. Include kyc_case_id, kyc_tier (basic / enhanced / EDD), and the provider (sanitized name — “provider_a” not the actual vendor name in events).
document_uploaded
Fires per document. Include document_type (enum: passport, national_id, drivers_license, proof_of_address), document_country, and retry_attempt. Never include the document itself or extracted values — those live in the KYC vendor system.
kyc_review
Fires when review starts — can be automated or manual. Automated review typically takes 2-120 seconds; manual review can take hours. Track queue_type and queue_position for manual cases.
kyc_approved / kyc_rejected
Terminal events. Approval is simple. Rejection is the event that matters most for analytics.
Reason codes must come from a controlled enum (document_unreadable, document_expired, mismatch_with_application, pep_flag, sanctions_hit, manual_review_required) — never free text. Free-text rejection reasons are simultaneously hard to analyze and likely to leak PII.
Stage 3 — Activation Events
account_funded
The first successful deposit. Include amount_bracket (under_100 / 100_to_1000 / 1000_to_10000 / over_10000) rather than the raw amount in events destined for product analytics. The exact amount is in your ledger; your analytics warehouse doesn’t need it for cohort analysis.
card_issued
For neobanks and debit card products. Include card_tier, card_type (virtual / physical), and issuance_time_hours.
recipient_added
Track when users add a recipient for transfers — it’s a strong activation signal for P2P products. Include recipient_type (self / third_party / business) but never the recipient name or IBAN.
first_transaction
The true activation moment. Must fire only once per user (use a boolean flag). Include time_to_first_transaction_days (from signup_completed) — this is the core cohort parameter for activation analysis.
Stage 4 — Transaction Events
transfer_initiated
User hits “send” in the transfer flow. Required: transaction_id, amount (rounded to a bracket for analytics, exact in the ledger), currency, transfer_type (internal / sepa / swift / card), destination_country.
transfer_completed
Funds settle. Same transaction_id joins to initiated. Include latency_seconds (end-to-end time) and provider_rail (which payment rail handled it).
transfer_failed
Must have failure_reason_code from a controlled list: insufficient_funds, recipient_rejected, compliance_hold, card_declined, technical_error. Never expose the provider’s raw error message in the event — sanitize or map.
transaction_disputed
User opens a dispute. Include dispute_type (fraud / service / other), time_since_transaction_hours, and channel (in-app / support / card_network). Critical for chargeback rate and fraud feedback loops.
PII Rules: What Events Must Not Carry
The principle is simple: events are for analytics; PII lives in regulated systems of record. Three concrete rules:
- Tokenize identifiers at the event boundary. User_id is opaque. IBAN and PAN never appear. Names never appear.
- Bucket sensitive numeric values. Amounts become brackets. Dates of birth become age ranges. Postal codes stay out entirely.
- Controlled enums, not free text. Free-text fields are where PII leaks. Every categorical parameter must be validated against a known list at emission time.
For the full regulatory context, see the DPA checklist for analytics vendors — fintech analytics pipelines almost always involve a processor that needs vetting.
Common Parameters for All Fintech Events
| Parameter | Type | Required | Notes |
|---|---|---|---|
user_id |
string | yes | Opaque, not email or IBAN |
account_id |
string | business | For business accounts with multiple users |
country_of_residence |
ISO 3166 | yes | Regulatory jurisdiction |
app_version |
semver | yes | For mobile |
kyc_tier |
enum | after KYC | basic / enhanced / EDD |
session_id |
string | yes | Rotates per session |
timestamp |
ISO 8601 | yes | Event occurrence time |
Data Layer Implementation
Three architectural choices that make or break a fintech event pipeline:
- Emit from backend services, not the client. Transaction events must come from the payment processor integration, not the app. Client-emitted transaction events can be spoofed and fail reconciliation with the ledger.
- Dual-write to audit log and analytics stream. Regulated events (KYC decisions, disputes) must persist in an immutable audit log. The analytics event is a sanitized sibling, not a replacement.
- Apply PII filtering at the SDK or gateway layer. Not in the warehouse. A naïve full-payload capture followed by “cleaning later” means PII is in your analytics system for the window between emission and cleanup — which is a GDPR incident waiting to happen.
Regulatory Notes
Three regulations shape fintech event schemas in the EU:
- PSD2 / PSD3 — Strong Customer Authentication requirements affect which events are required for audit; transaction_disputed must capture SCA status.
- AMLD6 — Anti-money-laundering directive requires audit trails for KYC decisions, dispute investigations, and certain thresholds. Events fire; the audit trail persists separately.
- GDPR Article 22 — Automated KYC decisions that have “significant effects” (which rejection does) require a human-review mechanism. Your kyc_rejected event should include
auto_or_manualso you can prove compliance.
For legal basis considerations, see legitimate interest vs consent — fintech product analytics on authenticated users often passes the LIA, but onboarding analytics (anonymous visitors) needs consent.
Validation Checklist
- No event payload contains names, emails, IBANs, PANs, or full addresses
- All amounts are in plan currency with
currencyset; brackets used for analytics-destined events - KYC rejection reason is a controlled enum, not free text
- transaction_id joins initiated, completed, failed for the same logical transfer
- first_transaction fires exactly once per user
- Events fired from backend, not client, for anything transaction-related
- Automated decisions flag
auto_or_manualfor Article 22 traceability
FAQ
How is fintech event tracking different from ecommerce?
Three major differences: KYC is the largest funnel drop-off (no equivalent in ecommerce), regulated data must stay out of analytics events (ecommerce PII rules are less strict), and transaction events come from backend services rather than the client (because client-side can be spoofed and must reconcile to the ledger). The underlying event pattern is similar; the constraints are tighter.
Can I use Amplitude or Mixpanel for fintech analytics?
Yes, with strict payload discipline. Third-party product analytics tools are fine for the events covered here because the payloads do not contain PII or regulated data. The caution is at the SDK layer: prevent automatic capture of form field values, URL parameters, or device fingerprints that could leak identity. Most tools offer a deny-list for this.
Should I track IP addresses in fintech events?
Not in product analytics events. IP addresses are personal data under GDPR and useful for fraud detection, so they belong in the fraud pipeline with appropriate legal basis and retention. In analytics, use country derived from IP (already geolocated and anonymized) instead of raw IP.
How do I handle KYC rejection analytics without exposing rejection reasons to the user?
The rejection reason in your event is the internal reason code (document_unreadable, pep_flag, sanctions_hit). The user-facing message is a separate, less-specific message controlled by compliance. Do not mirror the internal reason code to the user — that leaks information that helps bad actors iterate. Track both separately.
What events do I need for chargeback rate reporting?
Three: transfer_completed (denominator), transaction_disputed (numerator within 120 days), and dispute_resolved (with resolution type: customer_won, merchant_won, duplicate). Chargeback rate is disputes lost or customer-won divided by completed transfers in the same cohort month.
Start with the KYC Funnel
If you’re building fintech events from scratch, instrument the KYC funnel first: kyc_started, document_uploaded, kyc_review, kyc_approved, kyc_rejected. That funnel alone will tell you where most of your onboarding revenue is lost and what to fix first. The rest of the schema builds on top of that foundation — and the PII discipline you develop there will carry into the transaction events later.