Week 4 · Day 1 & Day 2

OpenConnect RAAST &
Open CMS

Day 1 covers how RAAST transactions flow through the OpenConnect system using PACS messages. Day 2 covers how cards are managed through their full lifecycle using CMS.

Day 1 — RAAST / PACS Day 2 — Card CMS PACS002Callbacks Card AuthorizationLifecycle

Day 1 OpenConnect RAAST — PACS Messages & Callbacks

01 The Simple Idea

Real-life Analogy

Think of RAAST like a postal system between banks. When Bank A wants to send money to Bank B, it writes a letter in a very specific standard format — PACS. SBP is the post office that receives, checks, and delivers the letter.

OpenConnect is your company's mailroom — it writes the outgoing letters, sends them to SBP, receives the replies, and makes sure everything is delivered correctly. If SBP rejects the letter, OpenConnect records why and tells the bank what went wrong.

What is OpenConnect in the RAAST context?

OpenConnect (OC) is the middleware that handles real-time individual RAAST transactions — P2P transfers, IBFT, TF2.0, and more. It sits between the client bank and SBP, translates requests into the correct PACS message format, sends them to SBP, and handles whatever SBP sends back.

Every transaction that goes through OpenConnect leaves a trail in the TRANSACTIONS_LOG, TRANSACTIONS_LOG_REQ_RESP, and MX_MESSAGE tables you studied earlier.

02 PACS Messages — What They Are

PACS = Payment Clearing System messages

PACS is an international standard format for payment messages. SBP uses these to communicate with banks. Think of it as the official language that all banks and payment systems must speak. Every message has a specific code and meaning.

PACS.008

Credit Transfer Initiation

The outgoing payment request. When a bank wants to send money, it sends a PACS.008 to SBP. This is the "please transfer this money" message.

PACS.002

Payment Status Report

SBP's reply to a payment. Contains either ACSP (accepted, processing) or RJCT (rejected). This is what you trace as L2.

PACS.004

Payment Return

Used when a payment needs to be reversed or returned. Money goes back to the sender. Like an official refund message between banks.

PACS.028

Payment Status Request

Sent when you want to ask SBP for the status of a transaction that hasn't been responded to yet. A follow-up enquiry message.

💡 As L2: PACS.002 is the one you will trace most. It tells you definitively whether SBP accepted or rejected a transaction — and if rejected, the exact reason code tells you why.

📋 PACS.002 — Status Codes You'll See

Code	Meaning	What to do as L2
ACSP	Accepted — Settlement in Process. SBP received it and is processing.	Monitor — wait for final settlement confirmation
ACSC	Accepted — Settlement Completed. Money has moved successfully.	All good — transaction is done, inform client
RJCT	Rejected. SBP refused the transaction — see reason code.	Investigate — check reason code, inform client
AC01	Reject reason: Invalid account number / IBAN incorrect	Client sent wrong IBAN — verify and resend
AM04	Reject reason: Insufficient funds in sender account	Client account has no balance — not a system issue
BE04	Reject reason: Missing or invalid beneficiary address	Beneficiary details incomplete — fix and resubmit
TM01	Reject reason: Transaction received outside SBP window	SBP maintenance window — retry during operating hours

03 Callback Handling

What is a Callback?

After SBP processes a transaction, it doesn't wait for you to ask — it pushes the result back to you automatically. That push is called a callback. OpenConnect has a dedicated endpoint that receives these callbacks from SBP and processes them.

If the callback is received and processed correctly — the transaction status is updated in the database and the client is notified. If the callback fails to deliver — the transaction can get stuck in a pending state even though SBP already has the answer.

📨 PACS.002 Flow — From SBP to Client

🏛️

Step 1 — SBP

SBP sends PACS.002 to OpenConnect

After processing the transaction, SBP posts the status report (ACSP or RJCT) back to the OpenConnect REST API endpoint. This is the callback.

POST /oc/api/v1/raast/callback → PACS.002 payload

🔌

Step 2 — OpenConnect

REST Handler receives and parses the message

OpenConnect's REST handler receives the PACS.002, validates the format, extracts the transaction ID and status, and stores the raw message in MX_MESSAGE table.

MX_MESSAGE table ← raw PACS.002 XML stored

🗄️

Step 3 — Database

Transaction status updated in DB

The transaction record in TRANSACTIONS_LOG is updated with the new status (ACSP/RJCT). TRANSACTIONS_LOG_REQ_RESP stores the full request and response pair.

TRANSACTIONS_LOG → STATUS updated to ACSP or RJCT

📬

Step 4 — Notification

Client bank is notified

OpenConnect pushes the result back to the originating bank. If the callback to the client fails — this is your breakpoint. The transaction stays pending in OC even though SBP already responded.

Callback → Client bank endpoint → Status delivered

04 RAAST Breakpoints — Where Things Go Wrong

🔴 Common RAAST Breakpoints for L2

Breakpoint	Where it happens	How to identify	Severity
Request never reached SBP	OC → SBP layer	Check MX_MESSAGE — if no outgoing record, OC never sent it	High
SBP replied but OC didn't receive	SBP → OC callback	TRANSACTIONS_LOG stuck in PENDING, no PACS.002 in MX_MESSAGE	High
OC received but status not updated	OC internal processing	MX_MESSAGE has response but TRANSACTIONS_LOG still PENDING	Medium
OC updated but client not notified	OC → Client bank	TRANSACTIONS_LOG shows ACSP but client reports no update	Medium
Transaction rejected — RJCT code	SBP decision	PACS.002 in MX_MESSAGE with RJCT + reason code	Info

05 Day 1 Lab — Trace a PACS.002

🔬 Lab: Trace a PACS.002 Through the DB

OpenConnect Schema

Find the transaction in TRANSACTIONS_LOG

Start here — find the transaction and check its current status.

SQL — OPEN_CONNECT schema

SELECT * FROM TRANSACTIONS_LOG
WHERE TXN_REF = 'TXN-9823';

→ Check STATUS column — PENDING means SBP reply not yet received or processed

Get the full request and response bodies

Check TRANSACTIONS_LOG_REQ_RESP for the raw messages.

SQL

SELECT REQUEST_BODY, RESPONSE_BODY, CREATED_AT
FROM TRANSACTIONS_LOG_REQ_RESP
WHERE TXN_REF = 'TXN-9823';

→ RESPONSE_BODY contains the PACS.002 XML — look for ACSP or RJCT

Check the raw PACS message in MX_MESSAGE

Find the actual XML message SBP sent back.

SQL

SELECT MESSAGE_TYPE, MESSAGE_BODY, DIRECTION, CREATED_AT
FROM MX_MESSAGE
WHERE TXN_REF = 'TXN-9823'
ORDER BY CREATED_AT ASC;

→ OUTBOUND = what OC sent to SBP (PACS.008) | INBOUND = what SBP replied (PACS.002)

Find all stuck PENDING transactions

Transactions pending for more than 1 hour that need attention.

SQL

SELECT TXN_REF, STATUS, CREATED_AT
FROM TRANSACTIONS_LOG
WHERE STATUS = 'PENDING'
AND CREATED_AT < NOW() - INTERVAL '1 hour';

→ Any result here = transactions stuck in OC. Investigate each one.

Day 2 Open CMS — Card Authorization Lifecycle

06 The Simple Idea

Real-life Analogy

Think about what happens when you tap your card at a shop. In about 2 seconds, many things happen invisibly — your card is verified, your bank is asked if you have funds, approval is given, the amount is reserved.

CMS (Card Management System) is the system that manages the full life of a card — from the moment it is issued to the moment it is blocked or expired. Every tap, every PIN attempt, every limit change goes through CMS.

What is Open CMS?

CMS (Card Management System) handles everything related to debit and credit cards — issuing new cards, activating them, setting limits, processing authorization requests, blocking stolen cards, and managing the full transaction history.

As an L2 engineer, you'll receive CMS-related tickets when customers can't use their card, when transactions are declining unexpectedly, or when a card needs to be blocked immediately during an S1.

07 Card Authorization Lifecycle

The Full Card Journey — From Issuance to Transaction

Every card goes through defined stages. Understanding these stages tells you exactly where in the lifecycle a problem is occurring.

📋

Issue

Card record created in CMS. Physical card printed and sent to customer.

✅

Activate

Customer activates card via app, ATM, or call. Card becomes usable.

💳

Authorize

Customer taps or swipes. CMS checks limits, status, and approves or declines.

⚙️

Settle

Approved amount is cleared and settled. Account balance updated permanently.

🔒

Block

Card blocked by customer or fraud system. No further transactions allowed.

❌

Expire/Close

Card expires or account closed. Card record archived in CMS.

08 Card Authorization Flow — What Happens When You Tap

💳 Real-time Card Authorization — Step by Step

🏪

Step 1 — Merchant

Customer taps card at POS terminal

The POS machine reads the card chip and sends an authorization request to the card network (Visa/Mastercard/1LINK).

🌐

Step 2 — Card Network

Network routes request to the issuing bank's CMS

The network (1LINK for domestic, Visa/MC for international) routes the request to the bank that issued the card. The request arrives at the CMS.

⚙️

Step 3 — CMS Checks

CMS runs authorization checks

CMS checks: Is the card active? Is it blocked? Does the account have enough balance? Is the amount within daily limits? Is the merchant category allowed?

All checks pass → APPROVED | Any check fails → DECLINED

📤

Step 4 — Response

CMS sends approval or decline back

Response travels back through the network to the POS in under 2 seconds. Approved = green light. Declined = transaction refused with a reason code.

🗄️

Step 5 — Settlement

Approved amounts are settled

At end of day (or in real time), approved authorizations are cleared and the account balance is permanently updated. The authorization hold is converted to a final debit.

❌ Common Decline Codes — What They Mean

Code	Meaning	L2 Action
51	Insufficient funds	Client side — account has no balance. Not a system issue.
54	Expired card	Card expiry date has passed. Issue a new card through CMS.
57	Transaction not permitted	Card not enabled for this transaction type (e.g. online, international). Update card settings in CMS.
61	Exceeds withdrawal limit	Daily limit reached. Check and update card limits in CMS if needed.
62	Restricted card	Card is blocked or restricted. Check card status in CMS.
91	Issuer unavailable	System issue — CMS or network is down. Check service health immediately.
96	System malfunction	System issue — internal CMS error. Check logs and escalate to L3.

09 Day 2 Lab — Trace a Card Transaction

🔬 Lab: Trace a Card Authorization Through CMS

CMS Investigation

Client says: "My card was declined. I have balance."

First check the card status in CMS — is it active, blocked, or restricted?

CMS check — card status

-- Check card status
SELECT CARD_NUMBER, STATUS, EXPIRY_DATE,
DAILY_LIMIT, INTL_ENABLED, ONLINE_ENABLED
FROM CARD_MASTER
WHERE CARD_NUMBER = '****1234';

→ If STATUS = BLOCKED → card was restricted. Check who blocked it and when.

Check the transaction authorization history

Find the declined transaction and its reason code.

CMS check — authorization log

SELECT TXN_ID, AMOUNT, STATUS,
RESPONSE_CODE, MERCHANT, TXN_TIME
FROM AUTH_LOG
WHERE CARD_NUMBER = '****1234'
ORDER BY TXN_TIME DESC
LIMIT 10;

→ RESPONSE_CODE = 62 means restricted card. RESPONSE_CODE = 61 means limit exceeded.

Check daily limit usage

See if the customer has already hit their daily spending limit.

CMS check — daily limit

SELECT DAILY_LIMIT, DAILY_USED,
(DAILY_LIMIT - DAILY_USED) AS REMAINING
FROM CARD_LIMITS
WHERE CARD_NUMBER = '****1234'
AND DATE(LIMIT_DATE) = CURDATE();

→ If REMAINING = 0, daily limit is exhausted. Client needs to wait until midnight reset.

Identify the root cause and respond to client

Map the response code to the reason and give the client a clear answer.

Decision tree

Code 51 → Insufficient funds → Not a system issue
Code 54 → Card expired → Reissue card in CMS
Code 61 → Limit exceeded → Inform client / update limit
Code 62 → Card blocked → Check who blocked it + why
Code 91 → System unavailable → P1 incident — check CMS health

→ Root cause identified → update Jira ticket → inform client with clear reason ✅

10 Real L2 Scenarios

Client says "RAAST transfer shows pending for 2 hours." You check TRANSACTIONS_LOG — status is PENDING. Check MX_MESSAGE — PACS.008 was sent but no PACS.002 exists. SBP never replied. You send a PACS.028 status request and escalate if SBP doesn't respond.

Client says "Transaction was RJCT by SBP — what's the reason?" You query MX_MESSAGE for the PACS.002 response, find the reason code AC01 — Invalid IBAN. You inform the client: the beneficiary IBAN is incorrect. The sender needs to verify and resubmit with the correct IBAN.

Customer calls bank saying "My card is being declined everywhere." You check CMS — RESPONSE_CODE = 62 (Restricted). You check the audit log — the fraud system auto-blocked it after 3 failed PIN attempts 1 hour ago. You unblock and notify the customer. All in 5 minutes.

All cards are declining at once — Code 91 across the board. This is a P1. CMS is unreachable or the network link is down. You open a bridge, check service health, check network connectivity, and escalate immediately. Every minute of Code 91 = hundreds of declined transactions.

✅ Week 4 · Day 1 & 2 Outcomes

Explain what OpenConnect is and its role between the bank and SBP in RAAST
Name the 4 PACS message types and what each one does
Read a PACS.002 and identify ACSP vs RJCT and the rejection reason code
Identify the 5 main RAAST breakpoints and which DB table to check for each
Trace a PACS.002 through TRANSACTIONS_LOG → REQ_RESP → MX_MESSAGE
Write the SQL to find stuck PENDING transactions older than 1 hour
Explain the full card lifecycle — Issue → Activate → Authorize → Settle → Block → Expire
Describe what happens step by step when a card is tapped at a POS
Map a decline code (51, 54, 61, 62, 91, 96) to its cause and the correct L2 action
Trace a declined card transaction through CMS — card status, auth log, limit usage

OpenConnect RAAST &Open CMS