Finpace brings a Sharia compliant BNPL foundation to KSA and the UAE

Finpace proud to announce that we are extending the banking platform to support Sharia compliant BNPL programs for institutions operating in KSA and the UAE. The objective is to give regulated teams a control plane for BNPL that stays consistent under operational load, integrates cleanly into existing estates, and remains governable as products evolve.

We are not positioning BNPL as a front end feature. The platform is built for the parts that actually drive outcomes at scale, lifecycle determinism, reconciliation, evidence, auditability, and secure integration across merchants, rails, and internal systems.

We built Finpace for institutions that want to own the product end to end, without inheriting operational ambiguity. BNPL is profitable only when lifecycle, reconciliation, and evidence are engineered into the runtime.

What Finpace provides for BNPL programs in the Gulf

A domain layer that can evolve without migrations

BNPL is a living domain. Plans, schedules, instalments, settlement terms, dispute artefacts, and servicing actions change as a program expands by merchant segment, channel, and governance guidance. Finpace provides a unified customer view and a generic entity engine that defines business entities dynamically without code changes or migrations, designed for high volume environments with event driven reconciliation and audit trails.

The core domain model uses a hybrid storage approach that combines structured metadata with JSONB payloads, so new entity types and attribute sets can be introduced without reworking the database, while required fields and business rules remain enforceable through application layer validation.

To keep the operational truth coherent across external participants, we include a relationship engine that maps external identifiers to internal UUIDs and supports typed, time bound associations and hierarchies. This is the substrate for linking merchant order IDs, PSP transaction IDs, internal servicing cases, and customer profiles into one consistent model.

Workflow orchestration as runtime behavior

BNPL at scale is dominated by exception paths. Partial refunds after one instalment, disputed fulfilment, asynchronous PSP updates, manual overrides, and retries that collide with customer servicing. Finpace treats lifecycle as an explicit runtime process through workflow orchestration powered by Zeebe and BPMN 2.0. It is designed for high performance, event driven execution, and resilience through built in state management, automatic retries, and incident handling.

The practical outcome is that BNPL is operated as observable processes rather than scattered conditional logic across services. Operations teams can monitor and resolve issues using full visibility into running processes.

Payment orchestration with explicit lifecycle states

Finpace includes enterprise payment orchestration with a layered architecture, contract driven REST APIs, service layer orchestration, and domain models that encapsulate business rules and transaction states.

It supports real time and batch processing, multi rail execution patterns, and an explicit transaction lifecycle that covers initiation, enrichment, authorization, and execution with status updates and event publishing.

Enrichment is designed to pull in the same dependencies consistently, including account lookup, fee calculation, and risk scoring, which is critical in programs where decisions must be reproducible and reviewable.

We also ship an authorization framework for multi party approvals and cryptographic payload verification using JWS, including cancellation workflows and an audit trail of authorization events.

Collections and mandate mechanics as first class capability

Collections cannot be treated as a retry loop. Finpace includes collection management with end to end mandate lifecycle management, rule based determination, planning, and execution. The platform documents full scheme mechanics including sequence types, mandate state machines, amendment handling, execution date planning, batch generation, and pre notification.

Even when a KSA or UAE program uses different rails than SEPA, the point remains that collections are implemented as governed lifecycle logic with explicit exceptions and planned execution, which is what institutions need to keep servicing and delinquency behavior consistent.

Reconciliation as a continuous control loop

The economics of BNPL are often decided by reconciliation latency and exception volume. We provide a reconciliation system initiated automatically by system events such as end of day and file received, with granular field extension logic that determines exactly which fields are allowed to update based on source authority. It categorizes discrepancies, auto resolves known patterns, and flags anomalies for operator review.

This matters in Gulf BNPL programs because truth is inherently distributed. Merchant platforms, PSP confirmations, internal contract state, and collection outcomes do not update in lockstep. Finpace treats reconciliation as a runtime guardrail rather than a finance only activity.

Auditability and observability designed for regulated operations

Finpace includes audit and history tracking features such as concurrency control, change detection based on deltas, and immutable audit logs that provide a defensible record of who changed what and when.

It also supports declarative auditing that captures request and response payloads, headers, and execution metrics, with correlation ID propagation for traceability across service layers and immutable audit logs designed for banking regulations.

On security, the platform supports OAuth2 and OIDC with JWT based authentication, RBAC with scopes, and method security. It also injects mandatory security predicates into dynamic queries to enforce strict data isolation.

Contract discipline is built in through contract first API design using OpenAPI 3.0, standardized machine readable errors aligned to RFC 7807, strict URL based versioning, and a validation framework that supports declarative constraints, custom business rules, and contextual validation groups.

How Finpace compares in the KSA and UAE buying context

In KSA and the UAE, many institutions start with traditional core banking suites because they provide breadth and existing vendor relationships. The issue in BNPL is that lifecycle and exceptions tend to escape the suite boundary and land in middleware, channel apps, and manual operations. Over time, the program becomes a distributed state machine with weak determinism.

Composable core platforms can reduce initial integration friction, but most teams still end up building the missing runtime around them, orchestration, incident handling, reconciliation, and audit capture. The BNPL program then inherits bespoke operations and bespoke controls.

Ledger first systems bring strength in postings, but BNPL outcomes are dominated by asynchronous external behavior, late updates, partial reversals, disputes, and operational recovery. The ledger remains necessary, but it is rarely sufficient as the operational control plane.

Finpace is structured around those runtime responsibilities. The platform provides workflow orchestration with resilience and operational visibility, payment and collection lifecycle primitives, reconciliation triggered by events with field level authority rules, and audit and authorization mechanics that behave as part of the system.

Availability for Gulf institutions

Finpace is available for institutions in KSA and the UAE that want to launch Sharia compliant BNPL as an owned product line, integrated into their existing banking, wallet, and payments estate, with lifecycle control and operational truth engineered into the runtime.

If you want, I can tailor this announcement to your target buyer persona in the Gulf, bank transformation, EMI product, or regulated lender, and align the language to the specific Sharia structure your program uses, while keeping claims grounded in the platform capabilities above.