Program Models
Program models define the structure of a FINCI card program, the platform capabilities in scope, and the responsibility split between FINCI and the integrator.
Use this page to align the program structure, platform scope, and operating model before implementation begins.
For portal orientation and the implementation journey, start with Getting Started.
FINCI card program offerings
The portal covers the following FINCI card program models:
| Card program model | Overview |
|---|---|
BIN Sponsorship | Scheme-facing issuing model with program-specific technical and operational responsibilities. |
Co-Branded Card Programs | Co-branded card programs delivered on FINCI issuing, processing, and card-servicing infrastructure. |
Crypto MiCA-Compliant Card Programs | Card programs for regulated crypto businesses delivered on the same FINCI platform and APIs, with program-specific setup and operating responsibilities. |
Commercial Cards via API | Commercial card programs integrated through FINCI APIs and webhooks, with the integrator operating the business application, internal control model, and authorization decisioning when that model is used. |
Across FINCI card programs, issuance is structured for eligible EEA-linked customers, including organizations established in the EEA, individuals residing in the EEA, and customers with another relevant EEA connection. Cards are accepted worldwide by default, subject to scheme acceptance and any program-specific controls.
Program definition
Before implementation begins, align the program definition across three areas. Those decisions shape the API flows, webhook responsibilities, operating model, and launch path.
Program structure
Define the program model, customer setup, product model, and launch countries.
| Decision area | Scope |
|---|---|
Program model | BIN Sponsorship Co-Branded Card Programs Crypto MiCA-Compliant Card Programs Commercial Cards via API |
Customer model and onboarding | Whether the program serves businesses, individuals, or both; who owns onboarding and verification; and which FINCI records must exist for that setup |
Product model | Debit, prepaid, or credit setup, together with the program funding and settlement approach |
Launch countries | Countries included in the first launch, together with the card products and services included at launch |
Card and customer experience
Define how cards are issued, tokenized, authenticated, and accepted.
| Decision area | Scope |
|---|---|
Issuance profile | Virtual cards, physical cards, or both |
MDES tokenization | Merchant tokenization, Apple Pay, and Google Pay |
3D Secure and merchant whitelist | 3D Secure setup and merchant whitelist configuration |
Acceptance geography | Domestic-only or worldwide card acceptance |
Controls and operations
Define how the live program is controlled, operated, and supported.
| Decision area | Scope |
|---|---|
Decisioning model | Authorization decision ownership between the integrator and FINCI |
Control model | Spending limits, MCC controls, ATM rules, geography rules, and related policy controls |
Transaction lifecycle | Authorization, clearing, reversal, return, and reconciliation handling |
Operational ownership | Shared-responsibility split for support, monitoring, notifications, and operational handling |
FINCI platform capabilities
Every FINCI card program is built on the same core platform. Additional capabilities and services depend on the program structure, product setup, and responsibility split.
Baseline platform capabilities
| Capability | Scope |
|---|---|
Card issuing and processing infrastructure | Core issuing and transaction-processing layer. |
Card lifecycle APIs | APIs for setup, issuance, and card operations. |
Webhook notifications | Real-time webhook notifications for authorization and transaction events. |
Webhook notifications are part of the core event model. In integrator-managed decisioning setups, authorization webhooks also carry real-time decision requests.
Additional product capabilities
These capabilities vary by program model and product setup.
| Capability | Scope |
|---|---|
Virtual card products | Virtual and digital-first card issuance. |
Physical card fulfillment | Program card design, personalization, production, and delivery for physical card programs. |
Mobile wallet tokenization | MDES tokenization for Apple Pay, Google Pay, and merchant tokenization. |
3D Secure | 3D Secure flows and merchant whitelist configuration. |
Payments API access | API access to the transaction and reconciliation data used for ledger matching. |
Additional program services
These services vary by operating model and delivery setup.
| Service | Scope |
|---|---|
Authorization decisioning | FINCI-managed decisioning. |
Customer verification and onboarding | Support for KYC, KYB, and reliance-based customer onboarding models. |
OTP messaging | OTP support for wallet token provisioning and 3D Secure flows. |
Program responsibility matrix
Responsibility split varies by program structure. The matrix below reflects the baseline FINCI-versus-integrator split used across integrator-operated program setups.
| Area | FINCI | Integrator |
|---|---|---|
Issuing platform | Issuing, processing, and card services | Business application and user journeys |
API and webhook layer | APIs, webhooks, and environment support | Integration and orchestration |
Customer verification and onboarding | Verification support included in the program setup | Onboarding ownership and any retained verification activities |
Card lifecycle and servicing | Card-management capabilities such as status, stage, PIN, and limits | Cardholder-facing servicing flows and use of those controls in the integrator platform |
Authorization | Authorization messaging and webhook delivery | Decisioning where integrator-managed |
Spending controls | Card-platform configuration | Internal spending limits, allocation rules, and policy controls |
Reconciliation and reporting | Payments API access and transaction data | Internal ledger, reconciliation, and reporting |
Security and operations | Platform-side security controls | Credential handling, monitoring, and environment operations |
Use this matrix as the baseline responsibility view. Verification, onboarding, and decisioning ownership vary the most by program structure and operating model.
The detailed authorization guides describe integrator-managed decisioning first. Where FINCI-managed decisioning applies, webhook delivery still applies, but approval logic remains on the FINCI side.
BIN sponsorship programs may require a broader responsibility model defined during program setup.