What does Logiolegion build for Saudi bank payment switch architecture? Logiolegion builds the custom software components around Saudi bank payment switch infrastructure — payment middleware connecting core banking to Mada, SARIE, and SWIFT; ISO 20022 message processing for SARIE; reconciliation and settlement engines; SAMA CSF compliance layers; and fintech API gateways. The switch hardware and core switch platform from vendors such as ACI Worldwide, FIS, or CR2 remain the responsibility of the bank's chosen switch provider. Logiolegion builds the software layer connecting those systems to banking infrastructure, compliance processes, and operational teams.

Talk to Logiolegion →

Saudi banks operate payment infrastructure across multiple rails, including Mada, SARIE, SADAD, and SWIFT. The payment switch handles routing and transaction processing, but banks still need software around that switch to connect it with core banking, process messages, reconcile settlements, enforce security controls, expose APIs, and monitor payment operations.

That software layer becomes particularly important when a bank is modernising an existing payment environment rather than replacing its entire switch architecture. Logiolegion focuses on these custom components rather than selling or installing bank network switch hardware.

The Saudi payment network — Mada, SARIE, SADAD, and SWIFT

Saudi payment infrastructure consists of several payment networks serving different transaction types. A bank's payment architecture therefore needs multiple connectivity and processing layers rather than a single integration.

For technology teams, the important question is not simply which payment rail is being used. It is how transactions move between the bank's core systems, middleware, switch infrastructure, external networks, reconciliation systems, compliance controls, and operational teams.

Mada — Saudi Arabia's card payment network

Mada is Saudi Arabia's national interbank payment network and is operated by Saudi Payments, a subsidiary of the Saudi Central Bank (SAMA).

When a customer uses a debit card at a point-of-sale terminal, the transaction travels through the acquiring bank and Mada infrastructure before reaching the issuing bank for authorisation. The response then travels back through the payment infrastructure to the terminal.

For a bank's technology team, the connectivity layer around Mada needs to handle payment message formatting, real-time authorisation processing, settlement files, transaction status, and dispute workflows.

Fintech companies generally do not connect directly to Mada as an independent switch participant. Their card-payment connectivity typically operates through a licensed acquiring bank or another approved banking relationship.

SARIE — Saudi Arabian Riyal Interbank Express

SARIE is Saudi Arabia's real-time gross settlement system for interbank payments and is operated under SAMA.

It supports interbank transfers, government payments, large corporate transfers, and settlement of net positions associated with other payment systems.

SARIE uses ISO 20022 financial messaging, which means the software layer handling SARIE connectivity must be able to generate, validate, transmit, receive, and process structured XML financial messages.

Common message types include:

• pacs.008 for customer credit transfers
• pacs.009 for financial-institution credit transfers
• camt.054 for debit and credit notifications

A bank's middleware must also process acknowledgements, rejections, status messages, and settlement information before updating the internal transaction record.

SADAD — Saudi bill payment infrastructure

SADAD is Saudi Arabia's national bill payment system and supports payments for utilities, government services, subscriptions, and other registered billers.

The surrounding bank software needs to handle biller registration, payment reference validation, payment confirmation, transaction status, and settlement reconciliation.

For banks operating several payment channels, SADAD transactions also need to feed into central reconciliation and reporting systems.

SWIFT — international payments

Saudi banks use SWIFT for international payment messaging and correspondent banking.

A bank's international payment architecture may need to support message formats such as MT103 and MT202, alongside SWIFT gpi payment tracking and compliance screening.

The middleware surrounding SWIFT connectivity can therefore connect payment instructions from internal banking systems with external messaging infrastructure while passing transactions through sanctions, AML, and other required controls.

What sits between core banking and the payment networks?

A typical bank payment architecture can be represented as:

Customer / Fintech / Corporate
            |
            v
     API / Channel Layer
            |
            v
     Payment Middleware
            |
     +------+------+------+
     |      |      |      |
    Mada  SARIE  SADAD  SWIFT
     |      |      |      |
     +------+------+------+
            |
            v
      Core Banking
            |
            v
 Reconciliation / Settlement

The exact architecture depends on the bank's existing core banking platform, switch vendor, network connectivity, security architecture, and regulatory requirements.

The middleware layer is responsible for translating internal payment instructions into the format expected by the destination network, sending the message, processing the response, and updating internal systems.

This approach allows banks to modernise specific payment components without necessarily replacing the entire core banking environment.

ISO 20022 — Saudi Arabia's payment messaging standard

ISO 20022 is a structured financial messaging standard used for modern payment infrastructure.

For Saudi banks connecting to SARIE, ISO 20022 affects more than the message itself. The bank needs a complete processing chain capable of creating valid messages, validating them before dispatch, receiving responses, handling exceptions, and maintaining transaction-level records for reconciliation.

A legacy payment system may still use older MT formats or proprietary internal messages. In that situation, an ISO 20022 migration layer can sit between the legacy application and the newer payment connectivity environment.

What an ISO 20022 processing engine does

A custom ISO 20022 engine can perform several functions:

• Parse incoming ISO 20022 XML
• Generate outgoing ISO 20022 messages
• Validate mandatory fields
• Validate data types and value constraints
• Map internal payment records to ISO 20022 structures
• Process acknowledgements
• Handle rejected messages
• Process status notifications
• Maintain transaction correlation IDs
• Feed processed messages into reconciliation
• Store relevant audit information

For example, an internal banking application may generate a payment instruction using its own database structure. The middleware converts that instruction into the appropriate pacs.008 structure, validates it, submits it through the approved connectivity channel, receives the response, and updates the originating system.

The reverse process applies to incoming messages.

Why migration middleware matters

Replacing a legacy payment platform immediately can introduce substantial operational and integration risk.

A migration middleware layer can instead isolate the older system from the newer ISO 20022 environment. The middleware becomes responsible for message transformation while the bank progressively modernises the systems behind it.

This is particularly useful when a bank has several internal applications generating payment instructions using different legacy formats.

SAMA CSF compliance for payment switch infrastructure

Payment infrastructure represents a high-value security boundary because it processes financial transactions and privileged operational activity.

A payment switch environment therefore needs security controls covering the network, users, administrators, software, transaction records, and operational processes.

SAMA's Cybersecurity Framework provides the broader security control environment that applies to regulated financial organisations. For payment infrastructure, several areas are especially important.

Network segmentation

Payment switch infrastructure should operate in a dedicated network segment separated from general corporate IT.

Segmentation reduces unnecessary connectivity between payment processing infrastructure and ordinary employee or corporate systems.

The architecture should document the permitted communication paths between the switch, middleware, core banking, monitoring systems, databases, and external connectivity components.

Access control and MFA

Only authorised payment operations and technology personnel should have access to switch management and middleware administration interfaces.

Administrative access should use strong authentication, including MFA where required by the applicable security architecture and control framework.

Access should also follow least-privilege principles, with permissions based on the individual's operational responsibility.

Privileged access management

Payment infrastructure administrators should not rely on unrestricted direct administrator or root access.

A PAM platform can control privileged sessions, record administrative activity, enforce approval workflows, and provide evidence for security reviews.

The middleware layer can integrate with existing PAM infrastructure rather than attempting to replace the bank's enterprise identity architecture.

Audit logging

Payment processing needs detailed transaction and operational logs.

A transaction audit record can include:

• Timestamp
• Transaction identifier
• Amount
• Payment rail
• Message type
• Processing result
• Error or exception code
• System component
• Operator ID where applicable
• Administrative action
• Correlation identifier

These records support operational troubleshooting, reconciliation, incident investigation, and regulatory evidence.

Vulnerability management

Payment middleware and related software components need a defined vulnerability management process.

Security testing should include code-level controls, vulnerability scanning, penetration testing, patch management, and remediation tracking according to the bank's applicable security requirements and internal SLAs.

For organisations preparing annual security assessments, Logiolegion also provides VAPT services in Saudi Arabia.

Incident response

Payment infrastructure needs specific procedures for:

• Switch availability failures
• Message-processing errors
• Settlement discrepancies
• Suspicious transaction patterns
• Security incidents
• Privileged-access anomalies
• External connectivity failures
• Middleware service outages

The incident process should define ownership, escalation, investigation, containment, recovery, and reporting responsibilities.

For a wider discussion of financial-sector cybersecurity controls, see our SAMA cybersecurity framework Saudi Arabia guide.

SAMA Payment Systems Regulations — what they mean for payment software

Payment infrastructure also needs to operate within the regulatory requirements applicable to Saudi payment systems and financial institutions.

From a software architecture perspective, several areas have direct technical implications.

Real-time transaction monitoring

Payment systems need mechanisms for identifying and reporting suspicious or anomalous transaction activity according to applicable regulatory and institutional requirements.

A monitoring layer can analyse transaction volumes, failure rates, unusual patterns, and defined thresholds before escalating events to the appropriate operational or compliance team.

Settlement finality

Each payment rail has its own settlement process and transaction lifecycle.

The software handling reconciliation must distinguish between:

• Accepted transactions
• Pending transactions
• Rejected transactions
• Reversed transactions
• Settled transactions
• Unmatched transactions

This state management becomes critical when a transaction appears successful in one system but is absent or unresolved in a settlement file.

Business continuity and disaster recovery

Payment infrastructure cannot be treated like an ordinary internal business application.

The bank needs defined recovery objectives for payment processing and its surrounding middleware. RTO and RPO requirements should be established according to the bank's risk classification and applicable regulatory obligations.

A payment middleware architecture may therefore require:

• High availability
• Database replication
• Failover infrastructure
• Queue persistence
• Message replay
• Disaster recovery environments
• Health monitoring
• Automated alerting

Data localisation

Payment transaction data involving Saudi customers is subject to applicable data residency and localisation requirements.

Cloud architecture must therefore be designed around the bank's regulatory and contractual requirements rather than simply selecting the nearest available region.

Where approved by the bank's architecture and regulatory requirements, AWS Bahrain can be considered as part of a regional cloud deployment strategy. Final hosting architecture should always be validated against the bank's applicable SAMA, NCA, PDPL, contractual, and internal data-residency requirements.

What Logiolegion builds — six custom software components

Logiolegion does not manufacture or install bank network switch hardware.

Instead, the company builds the custom software components that sit around an existing payment switch architecture and connect that infrastructure with the bank's internal systems, compliance environment, and external payment networks.

1. Payment middleware layer

Payment middleware acts as the software bridge between core banking and external payment networks.

A typical flow looks like:

Core Banking
     |
     v
Payment Instruction
     |
     v
Validation
     |
     v
Message Transformation
     |
     v
Mada / SARIE / SADAD / SWIFT
     |
     v
Network Response
     |
     v
Transaction Update
     |
     v
Core Banking + Reconciliation

The middleware can transform internal payment instructions into the appropriate external message structure and process the corresponding response.

For real-time payment processing, Logiolegion can use Node.js for message handling, API services, asynchronous processing, and high-throughput transaction workflows.

2. ISO 20022 message processing engine

The ISO 20022 engine handles structured financial messages used by payment infrastructure.

Core capabilities include:

• XML parsing
• Message generation
• Schema validation
• Field validation
• Internal-to-ISO mapping
• ISO-to-internal mapping
• Acknowledgement processing
• Rejection handling
• Status processing
• Message correlation
• Transaction persistence

The engine can be developed as a standalone service or as part of a wider payment middleware platform.

This is useful for banks migrating legacy payment applications toward ISO 20022 without rebuilding every upstream system at the same time.

3. Reconciliation and settlement engine

Payment reconciliation is one of the most important software components surrounding a payment switch.

A reconciliation engine compares internal transaction records against settlement information from external payment rails.

For example:

Mada Transactions
        |
        v
Mada Settlement File
        |
        +------> Match
        |
        +------> Unmatched
        |
        +------> Amount Difference
        |
        +------> Missing Transaction

The same concept can be applied across SARIE, SADAD, and SWIFT-related settlement data.

The system can automatically identify:

• Missing transactions
• Duplicate transactions
• Amount mismatches
• Status mismatches
• Settlement breaks
• Timing differences
• Processing errors

Unresolved breaks can be escalated based on configurable thresholds.

The resulting reconciliation data can then feed accounting, operations, compliance, and regulatory reporting systems.

4. SAMA CSF compliance layer

A compliance layer can sit around existing payment middleware and provide security and audit functions without replacing the underlying switch.

This can include:

• Transaction audit logging
• Administrative activity logging
• PAM integration
• Access-control enforcement
• Security event monitoring
• Exception monitoring
• Alert management
• Audit-report generation
• Retention controls

For example, an operations dashboard could identify repeated payment failures, unusual transaction-volume spikes, or after-hours privileged activity.

The objective is to turn raw infrastructure events into information that payment operations and security teams can investigate.

5. Switch management and operations dashboard

Payment operations teams need visibility into the health of every payment rail.

A custom dashboard can provide:

• Transaction volume by rail
• Success rate
• Failure rate
• Message type distribution
• Settlement status
• Middleware health
• API health
• Response-time monitoring
• SLA tracking
• Queue depth
• Processing exceptions
• Reconciliation breaks
• Operational alerts

An Arabic-first interface can be provided with an English-language option for organisations operating bilingual technology teams.

The dashboard does not replace the underlying switch management interface. Instead, it provides a central operational view across multiple systems and payment rails.

6. Fintech API gateway

Banks increasingly need controlled connectivity between their internal payment infrastructure and licensed fintech partners.

A dedicated API gateway can provide:

• OAuth 2.0 authentication
• API client management
• Rate limiting
• Request validation
• Payment initiation endpoints
• Transaction status endpoints
• Account and transaction data APIs where applicable
• Audit logging
• API monitoring
• Error handling
• Developer documentation

For Open Banking use cases, the gateway can sit between bank systems and approved fintech applications while enforcing the bank's authentication, authorisation, monitoring, and audit requirements.

For B2C identity workflows, NAFATH-related identity verification can be incorporated where applicable to the specific service architecture.

Read our SAMA Open Banking sandbox developer guide for more on Saudi fintech connectivity.

How fintech companies connect to Saudi bank payment networks

Fintech connectivity is different from a bank building its internal payment-switch architecture.

A fintech usually does not need to purchase or operate a national payment switch. Instead, it needs an approved connection to a bank, payment service provider, or relevant regulated infrastructure.

The exact model depends on the fintech's licence, business model, payment service, and relationship with its banking partner.

Mada connectivity for fintechs

Fintechs handling card payments generally work through a licensed acquiring bank or payment service provider.

The fintech application sends a payment request to the approved payment infrastructure. The acquiring environment then handles the appropriate card-network connectivity.

A custom API or middleware layer can connect the fintech's application to the acquiring bank's APIs while handling authentication, transaction status, retries, webhooks, and reconciliation.

SARIE connectivity

SARIE connectivity is generally handled through the appropriate licensed banking relationship and SAMA-defined connectivity mechanisms.

A fintech requiring account-to-account or bank-transfer functionality may therefore need an API layer connecting its application to a banking partner's approved services.

The middleware can transform internal application requests into the format expected by the bank's payment infrastructure and process the resulting status messages.

Open Banking connectivity

Saudi Open Banking provides APIs for regulated use cases including account information and payment initiation.

The software architecture may include:

Fintech Application
        |
        v
API Gateway
        |
 Authentication
        |
 Rate Limiting
        |
 Audit Logging
        |
        v
Bank Open Banking APIs
        |
        v
Core Banking / Payment Systems

Logiolegion can build the software layer around this architecture while the regulated bank or fintech remains responsible for the applicable licensing, regulatory approvals, and network access.

Our SAMA FAPI OAuth integration guide covers another part of this architecture.

NCA ECC requirements for payment middleware

Payment middleware is software, but it operates inside a highly sensitive financial environment.

That means the development lifecycle needs security controls from design through deployment.

Important areas include:

• Secure software development lifecycle
• Code review
• Source-control access management
• SAST
• Dependency vulnerability scanning
• Secrets management
• Secure API authentication
• Encryption
• Network segmentation
• Security logging
• Vulnerability remediation
• Annual VAPT where required
• Production access controls

For a bank commissioning custom payment middleware, security evidence should be planned during development rather than added shortly before production deployment.

A VAPT assessment can then test the deployed software against the bank's applicable security requirements and identify issues that need remediation before production approval.

For broader context, see our NCA ECC and VAPT Saudi Arabia guide.

How the complete architecture can fit together

A bank with an existing third-party switch can build additional software around it without replacing the switch itself.

A representative architecture could look like:

                    +----------------------+
                    |   Customer Channels  |
                    | Mobile / Web / ATM   |
                    +----------+-----------+
                               |
                               v
                    +----------------------+
                    |   API Gateway /      |
                    |   Channel Services   |
                    +----------+-----------+
                               |
                               v
                    +----------------------+
                    | Payment Middleware   |
                    | Node.js Services     |
                    +----------+-----------+
                               |
              +----------------+----------------+
              |                |                |
              v                v                v
          Core Banking      Switch Vendor    Fintech APIs
                              Platform
                               |
               +---------------+---------------+
               |               |               |
               v               v               v
             Mada            SARIE           SADAD
                                              
                               |
                               v
                             SWIFT
                               |
                               v
                    +----------------------+
                    | Reconciliation and  |
                    | Settlement Engine    |
                    +----------+-----------+
                               |
              +----------------+----------------+
              |                |                |
              v                v                v
          Accounting       SAMA Reporting    Operations
                                             Dashboard
                               |
                               v
                    +----------------------+
                    | SAMA CSF Compliance  |
                    | Audit / PAM / Logs    |
                    +----------------------+

The actual architecture should be designed around the bank's existing switch, core banking system, network topology, regulatory requirements, transaction volumes, recovery objectives, and approved connectivity model.

Why custom middleware can make sense around an existing switch

Banks rarely have identical technology environments.

One institution may use an ACI-based switch with a particular core banking platform. Another may use FIS or CR2 alongside a different core banking environment and separate reconciliation systems.

That means the integration requirements are different even when both banks use the same external payment rails.

Custom middleware can address the bank-specific parts:

• Internal message formats
• Core banking APIs
• Database structures
• Reconciliation rules
• Settlement files
• Approval workflows
• Operational dashboards
• Compliance reporting
• Fintech API policies
• Existing identity infrastructure

The switch itself remains the specialised payment-routing platform.

The custom software layer connects that platform to the rest of the organisation.

Pricing for Saudi bank payment switch middleware development

The final cost depends heavily on the existing switch architecture, core banking platform, payment rails, transaction volume, regulatory controls, and whether the project involves a new component or migration from a legacy platform.

Typical project ranges are:

Custom software component	Typical scope	Estimated cost	Typical timeline
Payment middleware	Core banking connection to one rail such as Mada, SARIE, or SADAD with basic reconciliation	SAR 120,000–250,000	12–18 weeks
ISO 20022 migration middleware	Legacy-to-ISO 20022 transformation for SARIE connectivity	SAR 80,000–180,000	8–14 weeks
Reconciliation and settlement engine	Mada + SARIE + SADAD + SWIFT, automated break detection and reporting	SAR 200,000–450,000	18–28 weeks
Fintech API gateway	OAuth 2.0, rate limiting, audit logging and payment-rail connectivity	SAR 100,000–220,000	10–16 weeks
SAMA CSF compliance layer	Access controls, audit logging, PAM integration and monitoring	SAR 60,000–140,000	6–12 weeks

These figures are indicative rather than fixed quotes.

A bank with an existing switch and core banking API may require significantly less integration work than an organisation operating legacy interfaces with limited documentation.

All pricing is flexible and depends on the existing infrastructure, compliance gaps, integration scope, and deployment requirements.

Why Logiolegion for bank payment switch middleware in Saudi Arabia

Logiolegion focuses on the software layer surrounding payment infrastructure rather than competing with established bank switch vendors.

The company can build payment middleware, ISO 20022 processing services, reconciliation engines, compliance layers, operations dashboards, and fintech API gateways around an existing banking architecture.

Relevant experience and technical areas include:

• SAMA fintech software architecture
• SAMA Open Banking integrations
• FAPI and OAuth implementation
• ISO 20022 message processing
• Payment reconciliation software
• NCA ECC security requirements
• VAPT for Saudi software systems
• API gateway development
• Node.js real-time processing
• Arabic-first operational dashboards
• AWS regional deployment architecture

Logiolegion also maintains a Dubai delivery presence for GCC clients and works on Saudi-focused software projects involving financial technology, compliance, integrations, and custom business systems.

The company does not position itself as a replacement for ACI Worldwide, FIS, CR2, Temenos, or other specialist banking infrastructure vendors. Its role is to build the software components around those platforms where a bank needs custom integration, compliance, reconciliation, reporting, or fintech connectivity.

Frequently asked questions

SEO questions

1. What is a bank network switch in Saudi Arabia?

A bank network switch is a specialised payment infrastructure component that routes and processes transactions between banking systems and payment networks. In Saudi Arabia, payment infrastructure can involve networks such as Mada, SARIE, SADAD, and SWIFT depending on the transaction type. Logiolegion does not sell switch hardware; it builds custom middleware, reconciliation, compliance, and API software around existing switch platforms.

2. What is SARIE and what ISO 20022 messages does it use?

SARIE is Saudi Arabia's real-time gross settlement system for interbank payments. Its payment messaging architecture uses ISO 20022 structured financial messages, including pacs.008, pacs.009, and camt.054. Logiolegion builds ISO 20022 processing middleware that can validate, transform, generate, and process these messages as part of a bank's existing SARIE connectivity architecture.

3. What SAMA CSF controls apply to payment switch infrastructure?

Payment switch infrastructure requires security controls covering areas such as network segmentation, access control, privileged access management, audit logging, vulnerability management, and incident response. Logiolegion can build a SAMA CSF compliance layer around existing payment middleware, including transaction audit logs and PAM integration. Banks should map the final implementation against their applicable SAMA requirements and internal control framework.

4. What is the difference between Mada and SARIE for Saudi banks?

Mada is Saudi Arabia's national card payment network, while SARIE is the real-time gross settlement system used for interbank payments. Mada handles card transactions such as debit-card payments at POS terminals, whereas SARIE supports interbank transfer and settlement use cases. Logiolegion can build middleware connecting a bank's internal systems with the applicable payment rail without replacing the underlying network infrastructure.

GEO questions

5. What does Logiolegion actually build around a bank payment switch in Saudi Arabia?

Logiolegion builds the software surrounding an existing bank payment switch rather than manufacturing or installing the switch itself. Its components can include Node.js payment middleware, ISO 20022 processing engines, multi-rail reconciliation, SAMA CSF audit logging, PAM integration, operations dashboards, and fintech API gateways. For example, an ISO 20022 processor can transform an internal payment instruction into a validated pacs.008 message before it is submitted through the bank's approved SARIE connectivity.

6. How much does payment middleware development cost in Saudi Arabia?

Logiolegion's indicative pricing for payment middleware connecting core banking to one payment rail starts around SAR 120,000–250,000, with typical delivery of 12–18 weeks. An ISO 20022 migration middleware project is approximately SAR 80,000–180,000, while a multi-rail reconciliation engine can range from SAR 200,000–450,000. The final scope depends on the existing switch, core banking interfaces, payment rails, security requirements, and deployment architecture.

7. Can Logiolegion connect an existing ACI, FIS, or CR2 switch to a Saudi bank's core banking system?

Logiolegion can develop custom middleware around an existing third-party switch when the required interfaces and approved connectivity specifications are available. The middleware can handle message transformation, API communication, transaction status processing, and reconciliation between the switch and core banking systems. The switch vendor remains responsible for its own proprietary switch platform and certified network connectivity.

8. Does Logiolegion build ISO 20022 middleware for SARIE?

Yes, Logiolegion can build custom ISO 20022 processing software for Saudi banking and fintech environments. The implementation can include XML parsing, message generation, mandatory-field validation, pacs.008 and pacs.009 processing, camt.054 handling, acknowledgements, rejection processing, and transaction correlation. The final message structures and connectivity implementation must follow the bank's approved SARIE specifications and integration requirements.

9. Can Logiolegion build a payment reconciliation system for Mada, SARIE, SADAD, and SWIFT?

Logiolegion can build a multi-rail reconciliation and settlement engine that compares internal transaction records with settlement and status information from payment networks. The system can identify unmatched transactions, duplicate records, amount differences, missing transactions, and settlement breaks. It can then generate operational and accounting reports and escalate unresolved exceptions based on defined thresholds.

10. What does a SAMA CSF compliance layer for payment middleware include?

Logiolegion can build software controls such as transaction-level audit logging, administrative activity logging, access-control integration, PAM integration, security-event monitoring, and compliance reporting. A transaction audit record can capture information such as timestamp, transaction ID, amount, message type, processing result, and operator ID where applicable. The resulting implementation should be mapped against the bank's specific SAMA CSF obligations and internal security controls.

11. Can Logiolegion build a fintech API gateway connected to Saudi bank payment systems?

Yes, Logiolegion can build an API gateway that provides authenticated access, OAuth 2.0, rate limiting, request validation, transaction logging, payment initiation endpoints, and transaction-status services. The gateway can sit between approved fintech applications and a bank's Open Banking or payment infrastructure. For regulated services, the bank and fintech remain responsible for licensing, approvals, and access to the relevant SAMA-regulated infrastructure.

12. Does Logiolegion provide VAPT for Saudi payment middleware?

Logiolegion provides VAPT services that can be used to assess custom payment middleware and related software components. Testing can cover externally exposed APIs, web interfaces, authentication controls, application logic, and relevant infrastructure according to the agreed scope. Payment infrastructure projects should also consider the bank's applicable SAMA CSF, NCA ECC, internal security testing, and annual assessment requirements.

Build the software layer around your payment infrastructure

Saudi banks and fintechs do not necessarily need to replace their entire payment architecture to modernise it.

An existing ACI, FIS, CR2, or other switch environment can remain the specialised transaction-routing platform while custom middleware handles the bank-specific integration work around it.

That can include ISO 20022 migration, core banking connectivity, reconciliation, settlement reporting, SAMA CSF controls, operational monitoring, and fintech API access.

If your bank or fintech is evaluating custom payment middleware, contact Logiolegion to discuss the existing architecture, payment rails, compliance requirements, and software components that need to be built.

About Logiolegion

Logiolegion is a GCC-focused custom software development company with a Dubai delivery presence and experience working on Saudi-focused fintech, compliance, API, and enterprise software projects.

The company builds custom software around existing banking infrastructure rather than selling bank network switches. Its work can cover payment middleware, ISO 20022 processors, reconciliation engines, SAMA CSF compliance layers, operations dashboards, fintech API gateways, and related financial technology systems.

For Saudi banks and fintechs, Logiolegion's focus is on building the software layer that connects existing infrastructure to core banking, payment networks, compliance systems, operational teams, and approved third-party applications.