Core Banking

A core banking system processes daily transactions and updates the financial records on which banking services depend. Its functions commonly include customer and account management, deposits and withdrawals, lending, and accounting. The Federal Reserve Bank of Kansas City distinguishes these primary services from ancillary offerings such as payment processing and customer support. Its research concerns the United States; the distinction is useful for explaining software functions, rather than describing Iran's market structure. s1

This helps explain why a banking application and a core banking system are different subjects. A customer may encounter a service through a digital interface, while the underlying account records require separate processing. In Iran, Dotin's catalogue explicitly distinguishes rial core banking from internet banking, mobile banking, card management and a banking switch. A switch routes transaction messages; its inclusion in a supplier's portfolio does not make it interchangeable with the account system. s2

Dotin describes its rial core product as a centralized system that stores and processes banking information together, in contrast to branch-centred systems. The rial is Iran's currency; here it identifies a product's domestic-currency scope, rather than a price or financial statistic. The company lists event-driven operation, configurable parameters, integration with surrounding systems and customization among the product's characteristics. These are supplier descriptions, not independently tested findings. s2

Tosan's company-managed profile identifies banking software development and support as its business, serving banks and financial institutions. That establishes a relevant supplier identity, but does not establish which software version operates at a particular bank. A useful comparison therefore needs a defined product, institution, implementation date and functional scope. Supplier-level descriptions should not be treated as a complete inventory of deployed systems. s4

The Kansas City Fed describes three broad approaches: replacing the entire core, replacing components progressively, or augmenting the existing system. Each involves different integration and transition demands. This is an explanatory framework, not evidence that Iranian banks follow a prescribed sequence. s1

Dotin's first-person account of its Bank Sepah project illustrates the organizational breadth of an Iranian migration. It describes workstreams covering infrastructure and security, migration, training, gap analysis, implementation and operation, with specialist groups on both the bank and supplier sides. This account supports a description of the reported work, but does not independently demonstrate the project's overall success or customer experience. s3

Three approaches to core modernization

The diagram summarizes alternative modernization approaches discussed by the Kansas City Fed. It does not depict an Iranian bank's architecture or a mandatory implementation sequence.

An assessment needs to look beyond whether software has been installed. The Basel Committee's operational-resilience material emphasizes continuity testing, dependencies, third-party arrangements and incident recovery. These provide an international reference for evaluating operational questions; they are not presented here as verified Iranian legal requirements. s5

For readers, the practical distinction is between a supplier's advertised capability, a documented deployment and demonstrated operation under disruption. Those are separate evidence questions. This page does not rank Iranian providers because comparable deployment and resilience evidence was not established in the inspected material.