MEMEH — Architecture

Platform-to-Bank RTP Integration Overlay

LOCAL Stable

Main Site

MEMEH

MEMEH integration documentation

Portal scope

This portal supports onboarding, integration guidance, sandbox simulation, downloads, certification, and operational readiness.

Documentation

Docs Home Get Started Concepts Architecture Security Fintech Bank Control Plane UAT Operations Downloads API Reference

Architecture

MEMEH Core is the narrow orchestration runtime between payment platforms, trusted alias resolution, published route configuration, and Bank Adapters.

What MEMEH does

• Validates and normalizes payment-intent requests
• Resolves aliases and builds the canonical instruction
• Selects the route, dispatches, and records lifecycle evidence

What connected domain services do

• CA/CAS owns trusted alias resolution data
• Control Plane owns route publication
• Bank Adapter and participant own IPS mechanics and updates

MEMEH end-to-end architecture sequence diagram — Click to open full size. Diagram shows the authoritative Core runtime boundaries from payment intent through callback history.

Diagram legend (1–6)

Each step maps to the lifecycle section below.

Jump to lifecycle →

Payment intent submitted

The payment platform sends an authenticated request with an idempotency key.

Request normalized

MEMEH validates aliases, amount, currency, reference, description, and replay controls.

Aliases resolved

Trusted CA/CAS produces verified payer/payee financial addresses and servicer identifiers.

Instruction and route prepared

MEMEH builds the canonical instruction and selects the active route from the runtime snapshot.

Bank Adapter dispatch

The selected adapter communicates with the payee-side participant and IPS path.

Lifecycle closed

Callbacks are deduplicated, transitions validated, and status/event history exposed.

High-level model

A practical stack view of how responsibilities split across initiating clients, MEMEH, adapters, and banks.

1

Payment Platform / Fintech

Submits payment intents and consumes lifecycle status and event history.

2

Trusted CA/CAS

Resolves aliases to verified financial addresses and servicer identifiers.

3

Control Plane

Publishes versioned runtime snapshots containing active participant routes and adapters.

4

MEMEH Core

Validates, normalizes, resolves, builds canonical instructions, routes, dispatches, and tracks lifecycle.

5

Bank Adapter / Participant / IPS

Owns bank-specific translation, pain.013 initiation mechanics, and authoritative updates.

Components

Enablement Portal

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

Control Plane

Publishes versioned runtime route and adapter snapshots consumed by Core.

MEMEH Core

Payment-intent validation, trusted alias orchestration, canonical instruction routing, dispatch, and lifecycle state.

Bank Adapter

Bank-specific translation, participant/IPS communication, and callback return flow.

Request lifecycle

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

1

Payment intent submitted

The payment platform sends an authenticated request with an idempotency key.
2

Request normalized

MEMEH validates aliases, amount, currency, reference, description, and replay controls.
3

Aliases resolved

Trusted CA/CAS produces verified payer/payee financial addresses and servicer identifiers.
4

Instruction and route prepared

MEMEH builds the canonical instruction and selects the active route from the runtime snapshot.
5

Bank Adapter dispatch

The selected adapter communicates with the payee-side participant and IPS path.
6

Lifecycle closed

Callbacks are deduplicated, transitions validated, and status/event history exposed.

Security model

Security is enforced at the request boundary through authenticated clients, replay protection, controlled credential issuance, and auditable runtime configuration.

Authentication

Identity is established per integration boundary and used to authorize request submission.

Replay protection

Nonce/timestamp + idempotency prevent duplicate processing across retries and failures.

Controlled enablement

The portal issues credentials and production access through review, UAT, and readiness checks; Core remains machine-to-machine.

Read the Security guide →