A central financial services platform connecting portals and external banking networks

Multi-tenant · Multi-vendor · Configuration-driven

Financial services, connected.

A shared platform design for organizations to reach many financial service providers through one common integration model—and manage the people, money, and operations around every transaction.

Explore the service catalog Talk to Fortivin

Platform architecture overview · Capabilities shown describe the proposed design.

One common interface

One request model. A choice of configured providers.

14merchant services in launch catalog

4dedicated portal audiences

1shared integration model

Nconfigurable providers per service

Connect

Canonical APIs

Direct

Configured routing

Isolate

Organization scope

Operate

Full transaction lifecycle

01 / 06

Merchant service catalog

Many services. One connector model.

The launch catalog routes every merchant-facing service through a shared service-and-operation pattern. Add a service by configuring its catalog entry and provider—not by rebuilding the transaction pipeline.

14 services in this view

Domestic Money Transfer

DMT

IMPS / NEFT switch

Financial

BBPS · Online

Bill payment

NPCI Bharat BillPay operating unit

Financial

Mobile & DTH Recharge

Recharge

Recharge aggregator

Financial

Travel Booking

Travel

Bus, rail, air and hotel aggregator

Financial

BBPS · Offline

Assisted bill pay

Agent-assisted BBPS operating unit

Financial

Payment Gateway Collection

Gateway

Payment gateway vendor

Financial

Credit Card Bill Payment

CC Bill

BBPS or card-network bill-pay rail

Financial

Aadhaar Enabled Payment System

AePS

NPCI AePS switch

Financial

UPI ATM Withdrawal

UPI ATM

UPI switch and certified micro-ATM

Financial

Nepal Outward Remittance

Nepal Money

Cross-border corridor partner

Financial

Static QR

QR Static

UPI / QR switch

Collection instrument

Dynamic QR

QR Dynamic

UPI / QR switch

Collection instrument

Cash Management Services

CMS

Banking-partner CMS API

Financial

Payout

Payout / settlement vendor

Financial

Service availability depends on organization enablement and applicable vendor, rail, device, partner, and licensing arrangements. QR products are collection instruments; transaction execution is merchant-facing.

02 / 06

A common transaction lifecycle

A request enters. A normalized result returns.

Core processing and transaction persistence precede provider selection. For financial requests, a sent request that times out is marked unknown and checked—not blindly routed to another provider.

Accept

Validate caller, schema, permissions, idempotency, and organization service access.

Process core rules

Check limits and fees; place a wallet hold or call configured organization core functions.

Route

Select an eligible provider using service, org rules, health, priority, amount, and region.

Translate & secure

Map fields, serialize, authenticate, and apply the provider’s configured signing or encryption.

Normalize

Translate provider statuses and errors into a common response and transaction state.

Reconcile

Requery uncertain outcomes, process callbacks, and match settlement records.

Failover follows configured safety classes. A financial timeout after transmission becomes UNKNOWN and follows the status requery path.

03 / 06

Four portals · one platform

The right workspace for every role.

Separate audience experiences are designed to sit over a shared platform. Each portal has its own entry point and access boundary; the system console remains on a private path.

PortalUsersChannelAccess

Merchant

Users

Retailers and staff

Channel

Responsive web and Android

Access

Public internet

merchant.brand.in

Distributor

Users

Super Distributors and Distributors

Channel

Responsive web and Android

Access

Public internet

partner.brand.in

Organization admin

Users

Organization Admin, Manager, Finance, Support and Viewer roles

Channel

Web portal

Access

Public internet; organization IP allowlist optional

admin.brand.in

System admin

Users

System Owner and platform operations roles

Channel

Web console

Access

Private access via VPN / IP allowlist

console.brand-ops.in

Domain examples are placeholders from the architecture brief; final portal domains remain to be selected.

04 / 06

Operations built around the flow

A financial platform is more than the API.

The architecture treats access, approvals, ledgers, reconciliation, and monitoring as core platform responsibilities—not downstream add-ons.

Organization, roles & hierarchy

Service enablement, custom role permissions, configurable levels, and OWN / TEAM / ORGANIZATION / GLOBAL data scopes.

Wallets, limits & commissions

Double-entry ledger, holds, per-service limits, and commission and charge rules that follow each configured level.

Approvals & maker-checker

Configurable approval steps for sensitive actions: settlement, refunds, vendor configuration, users, and role changes.

Recon360 & financial reporting

Match platform, vendor, and bank records; manage exceptions, settlement cycles, billing, and reconciled reporting.

Vendor configuration & routing

Provider-specific auth, mapping, crypto, status, and error definitions with priority, health, and safe failover rules.

Requery, callbacks & monitoring

Handle pending and unknown states, callbacks, provider health, latency, failure ratios, and transaction visibility.

05 / 06 · Trust & Compliance

Boundaries designed into the platform.

Security, tenant isolation, auditability, and recovery are part of the proposed platform architecture—not claims of completed certifications or a live operational environment.

Discuss your security requirements

Organization isolation

Organization scope derived from identity; tenant rows carry organization scope and are filtered at the data layer.

API & vendor secrets

Request signing, IP controls, payload protection, and vault-referenced vendor credentials are in the design.

Audit & privacy

Configuration changes, approvals, transactions, and logins are auditable; sensitive fields are masked in logs.

India-region resilience

The brief proposes AWS Mumbai primary and Hyderabad warm standby, with planned data residency and rehearsed recovery.

Standards references

Reference material for common quality and payment-security frameworks. These links do not represent Fortivin certifications or completed assessments.

ISO/IEC 25000 PCI DSS PCI PIN SOC 2

06 / 06 · Start a conversation

Design the integration around your institution.

Share your requirements, service priorities, and existing core-system landscape with our team.

Contact Fortivin