MEMEH RTPO logo
Documentation menu
Docs Home Get Started Concepts Architecture Security RTP Guide Fintech Developer Guide Runtime Configuration UAT Operations Downloads API Reference

Architecture

MEMEH RTPO is the official Request-to-Pay orchestration platform of the Bank of Sierra Leone National Payment Switch. Its architecture separates human enablement, governed configuration, runtime orchestration, trusted addressing, provider connectivity, and the existing IPS flow.

What MEMEH RTPO does
  • • Enables and certifies approved request submitters and providers
  • • Governs participant BICs, adapter targets, fraud controls, and runtime snapshots
  • • Orchestrates requests and records authoritative lifecycle evidence
What connected domain services do
  • • CAS remains the addressing authority behind participant systems
  • • Participating providers own customer consent and RTP processing
  • • IPS remains the inter-participant switching and payment rail
Click to open full size. The diagram shows the current enablement, configuration, runtime, provider, and lifecycle boundaries.

Diagram legend (1–8)

Each step maps to the lifecycle section below.

Jump to lifecycle →
1
Checkout resolves both parties
The approved request submitter sends payer alias, payee alias, and the payee financial service participant BIC through the Secure Fintech Edge.
2
Core selects the participant boundary
Core validates the request and matches payee_bic to exactly one active trusted Participant Adapter. The caller never supplies an adapter URL.
3
Adapter resolves two aliases
The adapter calls the participant’s existing one-alias API separately for payer and payee, combines both successful results, and verifies the payee servicer.
4
Checkout submits selected addresses
The payer selects an eligible payer option and the request submitter binds its authorized payee option before sending the payment request.
5
Canonical instruction is dispatched
Core validates the fresh resolution, persists one instruction, and posts it to the same Participant Adapter.
6
Provider starts its RTP flow
The adapter posts to the configured provider RTP API. The provider owns customer consent and IPS interaction.
7
Provider returns lifecycle
The provider posts a stable lifecycle event to the adapter; the adapter restores correlation and forwards it to Core.
8
Core exposes outcome and history
Core deduplicates the event, enforces the state machine, and serves current status plus immutable event history.

High-level model

A practical stack view of how responsibilities split across enablement, request submitters, governed configuration, Core, adapters, providers, and IPS.

1
Enablement Portal
Governs access applications, administrator review, sandbox credentials, fintech workspace, downloads, UAT guidance, and audit records before runtime use.
2
Business / Biller / Government Service
Uses an approved checkout or payment platform to submit a payment request and consume lifecycle status.
3
Checkout / Request-Submitter Backend
Calls the Secure Fintech Edge with HMAC, payer/payee aliases, payee_bic, amount, currency, and reference. The edge injects its governed merchant_id.
4
Participant Alias API
Resolves one alias per authenticated adapter call using the participant’s existing CAS integration. The participant platform owns CAS credentials and token handling.
5
Central Addressing Service (CAS V2)
Acts as the trusted external authority for aliases, financial addresses, and servicer identifiers.
6
Runtime Control Plane
Governs the participant BIC directory, adapter targets, resolution mode, fraud controls, and published runtime snapshots.
7
MEMEH RTPO
Validates requests, selects the payee_bic participant boundary, verifies resolution results, builds canonical instructions, and tracks lifecycle.
8
Participant Adapter
Calls the participant alias API twice, combines results, posts the canonical initiation to the provider RTP API, stores correlation, and forwards lifecycle events.
9
Provider RTP Platform and IPS
The participating provider owns payer consent and the standard RTP/IPS exchange; IPS remains the national switching rail.

Components

Enablement Portal

Access applications, documentation, credentials, UAT evidence, downloads, and audit support outside the Core runtime.

Control Plane

Publishes versioned approved provider routes and adapter bindings consumed by Core.

MEMEH RTPO

Payment-request validation, CAS result handling, canonical instruction routing, dispatch, and lifecycle state.

Central Addressing Service (CAS)

Authoritative payer and payee alias resolution into verified financial addresses and servicer identifiers.

Bank Adapter

Relays canonical requests, stores provider correlation, and forwards provider lifecycle events. It does not create IPS messages.

Provider RTP Platform and IPS

The provider owns customer consent and RTP processing; IPS executes the standard inter-participant exchange.

Request lifecycle

The same sequence shown in the diagram, mapped to stages 1–8.

  1. 1
    Checkout resolves both parties
    The approved request submitter sends payer alias, payee alias, and the payee financial service participant BIC through the Secure Fintech Edge.
  2. 2
    Core selects the participant boundary
    Core validates the request and matches payee_bic to exactly one active trusted Participant Adapter. The caller never supplies an adapter URL.
  3. 3
    Adapter resolves two aliases
    The adapter calls the participant’s existing one-alias API separately for payer and payee, combines both successful results, and verifies the payee servicer.
  4. 4
    Checkout submits selected addresses
    The payer selects an eligible payer option and the request submitter binds its authorized payee option before sending the payment request.
  5. 5
    Canonical instruction is dispatched
    Core validates the fresh resolution, persists one instruction, and posts it to the same Participant Adapter.
  6. 6
    Provider starts its RTP flow
    The adapter posts to the configured provider RTP API. The provider owns customer consent and IPS interaction.
  7. 7
    Provider returns lifecycle
    The provider posts a stable lifecycle event to the adapter; the adapter restores correlation and forwards it to Core.
  8. 8
    Core exposes outcome and history
    Core deduplicates the event, enforces the state machine, and serves current status plus immutable event history.

Security model

The current implementation uses boundary-specific credentials, TLS requirements for production configuration, request and event idempotency, rate limits, controlled enablement, and auditable runtime configuration.

Authentication

Public client APIs use an issued bearer key. Internal and participant boundaries use separately governed service credentials and verified TLS under restricted implementation contracts.

Duplicate protection

A required JSON idempotency_key protects payment creation; stable provider event_id values protect lifecycle processing. HMAC nonce signing is not currently implemented in Core.

Controlled enablement

The portal records applications, review decisions, sandbox credentials, signed partner invitations, downloads, and audit events. Production enablement remains a formal operational gate.

Read the Security guide →
© 2026 MEMEH RTPO — MEMEH Request-to-Pay Orchestrator
Developer & Integration Portal