One data model across every fintech vendor.
Every KYC, KYB, payment, banking, fraud, and comms vendor emits a different response shape. FinQub's Universal Pivot Format normalizes them into one unified model — so your application code handles one schema regardless of which vendor served the request.
What is a Universal Pivot Format?
The Universal Pivot Format (UPF) is FinQub's unified data model across every fintech vendor category: KYC, KYB, payments, banking, fraud, sanctions, communications, and documents. Every vendor response is normalized into one consistent schema with standardized field names, confidence scores, decision states, and error categories. Your application code handles one data shape regardless of which vendor served the request.
Without a unified data model, every vendor is its own downstream dependency. Onfido's confidence scores live on a different scale than Jumio's. Stripe's payment status codes differ from PayPal's. Plaid's transaction categorization differs from Finicity's. Every one of those asymmetries becomes application code — retry logic per vendor, mapping tables per vendor, edge-case handling per vendor. Switching a vendor means rewriting all of it.
UPF inverts that relationship. Normalization happens once, at the platform edge. Your application consumes one typed schema. Swapping a vendor is a configuration change, not a downstream rewrite. Vendor-specific fields you need for edge cases are preserved in a structured raw payload — so you never lose fidelity for the sake of abstraction.
Before & after, across every vendor category
Every major fintech vendor category has a different shape. UPF flattens them all.
KYC identity verification
Onfido returns `confidence: 0.87`. Jumio returns `match_score: 87`. Sumsub returns `reviewResult.reviewAnswer: "GREEN"`. Your app handles three schemas.
All three become `{ decision: "pass", confidence: 0.87, reasons: [...] }`. Your app handles one schema.
Payment status
Stripe returns `status: "succeeded"`. PayPal returns `status: "COMPLETED"`. Braintree returns `status: "SETTLED"`.
All three become `{ status: "settled", timestamp: "...", rail: "card" }` with consistent state semantics.
Banking / aggregators
Plaid transaction category: `["Shops", "Food and Drink", "Restaurants"]`. Finicity: different taxonomy. MX: different again.
Unified `{ category: "dining", merchant: "...", amount: 42.50 }` — same across every aggregator.
Webhook events
Each vendor has its own webhook schema, signature validation, retry semantics, and event taxonomy. You maintain N handlers.
FinQub normalizes webhooks into one event stream with consistent payload shape and delivery guarantees. One handler.
Escape hatches — because every abstraction eventually hits an edge case
UPF doesn't lock you in. When you need vendor-specific behavior, three mechanisms preserve it without sacrificing the unified model for everything else.
Raw payload preservation
Every UPF object carries a structured `raw` field with the original vendor response. You get the normalized shape for the common case and the raw payload for vendor-specific fields you need.
Passthrough calls
Need to call a vendor endpoint FinQub doesn't yet wrap? Passthrough mode lets you make vendor-specific requests authenticated through FinQub, so you don't lose audit logging or observability.
Schema extensions
For vendor-specific fields that matter across your workflows, define typed extensions to the UPF model. Your application code stays strongly typed; vendor idiosyncrasies stay first-class.
Frequently asked questions
Stop building your orchestration layer. Start running on it.
Let's talk about what FinQub looks like for your stack — which tools you're running, where the pain is, and how quickly you can eliminate it.
Not ready to book a call? Apply for the Partner Program →