Week 4 · Day 3 & Day 4

Open ACS &
IBFT & Bill Pay

Day 3 covers how 3D Secure protects online card payments using OTP. Day 4 covers how interbank fund transfers and utility bill payments flow through the system.

Day 3 — ACS / 3D Secure Day 4 — IBFT & BillPay 3DSOTP IBFT LifecycleUBPS

Day 3 Open ACS — 3D Secure Flow & OTP

01 The Simple Idea

Real-life Analogy

Think of buying something online with your card. You enter your card details and then suddenly a box appears asking for an OTP sent to your phone. That extra step is 3D Secure.

Without it, anyone who steals your card number can shop online. With it, even if they have your card number, they can't complete the payment without your phone.

ACS (Access Control Server) is the system that generates and verifies that OTP. It is the gatekeeper of every online card transaction.

What is Open ACS?

ACS (Access Control Server) is the component that handles 3D Secure authentication for online card transactions. When a customer pays on a website, the payment page sends a request to the ACS. The ACS checks if the card is enrolled, sends an OTP to the customer's registered phone, and verifies the OTP before allowing the payment to proceed.

As L2, you deal with ACS when customers report "OTP not received", "payment page stuck", or "OTP entered correctly but transaction still failed". All of these point to different breakpoints inside the 3DS flow.

02 3D Secure Flow — Step by Step

🔐 3D Secure Authentication Flow

🛒

Step 1 — Customer

Customer enters card details on merchant website

Customer fills in card number, expiry, CVV on an online checkout. Merchant's payment gateway sends an authentication request to the card network.

🌐

Step 2 — Directory Server

Card network checks if card is 3DS enrolled

The card network's Directory Server checks if the card is enrolled for 3D Secure. If enrolled, the request is forwarded to the bank's ACS. If not enrolled, transaction may proceed without OTP or be declined.

Enrolled → route to ACS | Not enrolled → fallback decision

🔐

Step 3 — ACS

ACS generates and sends OTP to customer

The ACS receives the authentication request, validates the card, generates a one-time password, and sends it to the customer's registered mobile number via SMS. The customer sees an OTP input screen.

ACS → SMS Gateway → Customer's phone → OTP received

📱

Step 4 — Customer

Customer enters OTP on the payment page

Customer receives OTP on their phone and enters it in the OTP field. The entered OTP is sent back to the ACS for verification. OTP usually expires in 3 to 5 minutes.

✅

Step 5 — ACS Verification

ACS verifies OTP and sends authentication result

ACS checks the OTP — correct and within time limit = Authentication Successful. Wrong OTP or expired = Authentication Failed. The result is sent back to the merchant as an authentication response (Y = success, N = failed, U = unavailable).

Y = Authenticated | N = Failed | U = ACS Unavailable | A = Attempted

💳

Step 6 — Authorization

Payment proceeds to card authorization

If ACS returns Y, the merchant sends the authorization request to the bank. CMS processes the authorization (balance check, limit check) and approves or declines. Both ACS and CMS must pass for a successful online payment.

📋 ACS Authentication Status Codes

Code	Meaning	L2 Action
Y	Authentication Successful — OTP verified, proceed	All good — transaction moves to CMS authorization
N	Authentication Failed — wrong OTP or too many attempts	Check logs — customer entered wrong OTP. Check attempt count in ACS logs.
U	ACS Unavailable — system could not process the request	System issue — ACS is down or unreachable. Check ACS service health.
A	Attempted — 3DS was tried but card not fully enrolled	Monitor — bank attempted authentication. Merchant decides to proceed or not.
R	Rejected — bank rejects the transaction entirely	Investigate — check ACS logs for rejection reason.

03 ACS Breakpoints — Where 3DS Fails

Common Issues

OTP Not Received

SMS gateway is down or delayed
Customer's phone number not registered
Phone number changed but not updated in bank
Customer's network has no signal
ACS sent OTP but SMS provider failed delivery

System Issues

OTP Entered but Still Failed

OTP expired — customer took too long (over 5 min)
Customer entered OTP from old SMS, not latest
ACS database out of sync with card records
ACS returned U — service unavailable
Timeout between ACS and card network

💡 Golden rule for ACS tickets: Always check two things first — (1) did the ACS actually send the OTP (check ACS logs for SMS dispatch record) and (2) what response code did ACS return (Y/N/U/A/R). These two answers tell you 80% of what you need to know.

04 Day 3 Lab — Simulate 3DS Failure

🔬 Lab: Investigate a 3DS Authentication Failure

ACS Investigation

Client says: "Customer OTP not arriving"

Check the ACS authentication log — did the ACS even try to send an OTP?

SQL — ACS schema

SELECT TXN_ID, CARD_NUMBER, AUTH_STATUS,
OTP_SENT, OTP_ATTEMPTS, CREATED_AT
FROM ACS_AUTH_LOG
WHERE CARD_NUMBER = '****5678'
ORDER BY CREATED_AT DESC
LIMIT 5;

→ OTP_SENT = N means ACS never dispatched the OTP. Check SMS gateway. OTP_SENT = Y but customer says not received = SMS delivery failure.

Check OTP attempt history

How many times did the customer try? Did they enter the wrong OTP?

SQL

SELECT TXN_ID, ATTEMPT_NUMBER,
OTP_ENTERED, RESULT, ATTEMPT_TIME
FROM ACS_OTP_ATTEMPTS
WHERE TXN_ID = 'TXN-ACS-001';

→ 3 FAILED attempts = customer entered wrong OTP 3 times. Card may be temporarily blocked for online payments.

Check if the card is enrolled for 3DS

If the card is not enrolled, the ACS will not send an OTP at all.

SQL

SELECT CARD_NUMBER, ENROLLED_3DS,
MOBILE_NUMBER, ENROLLMENT_DATE
FROM ACS_CARD_ENROLLMENT
WHERE CARD_NUMBER = '****5678';

→ ENROLLED_3DS = N means card is not enrolled. Customer needs to register their mobile number for 3DS at the bank.

Find all transactions where ACS returned U (unavailable)

ACS returning U to all transactions means the system is down — this is a P1.

SQL — find system-wide ACS failure

SELECT COUNT(*) AS FAILED_COUNT
FROM ACS_AUTH_LOG
WHERE AUTH_STATUS = 'U'
AND CREATED_AT > NOW() - INTERVAL '15 minutes';

→ High count of U in last 15 minutes = ACS is down. Raise P1 immediately and check ACS service health.

Day 4 IBFT & Bill Pay — Funds Transfer Lifecycle

05 The Simple Idea

Real-life Analogy

Think of IBFT like a courier service between banks. You hand a parcel (money) to your courier (your bank), they check it, label it, send it through the courier network (1LINK), and deliver it to the recipient at another bank. Every step is logged.

Bill Pay is the same idea but for utility companies — instead of sending money to another person, the money goes to LESCO, SNGPL, PTCL or any registered utility company. The bank looks up the consumer's bill, confirms the amount, and processes the payment.

What is IBFT?

IBFT (Inter Bank Funds Transfer) is the service that allows customers to transfer money from their account in one bank to an account in a different bank. It goes through the 1LINK switch which acts as the central router between all Pakistani banks.

IBFT is the most common daily transaction type you will support — salary payments, personal transfers, business payments. Most IBFT issues come down to wrong IBANs, account status problems, or 1LINK connectivity issues.

What is Bill Pay (UBPS)?

UBPS (Utility Bill Payment System) allows customers to pay their electricity, gas, water, telephone, and other utility bills directly through their bank. The bank is connected to each utility company's billing system. The customer enters their consumer reference number, the system fetches the bill amount, and the payment is processed.

06 IBFT Transaction Lifecycle

🔄 IBFT — Full Transfer Lifecycle

👤

Step 1 — Initiation

Customer initiates transfer in banking app

Customer enters beneficiary IBAN, amount, and remarks. Before confirming, the app calls TF2.0 (Title Fetch) — fetches and shows the beneficiary's name from the destination bank for confirmation.

TF2.0 request → Destination bank → Returns account name

🏦

Step 2 — Sender Bank Validation

Sender bank validates the request

Sender bank checks: Does the sender account have sufficient balance? Is the account active? Is the amount within transfer limits? If all pass — the request is sent to 1LINK.

Balance check → Limit check → Account status check

🔀

Step 3 — 1LINK Routing

1LINK receives and routes to destination bank

1LINK receives the IBFT request, identifies the destination bank from the IBAN, and routes the request to that bank's switch interface. 1LINK logs every hop and assigns a unique switch reference number.

1LINK Switch Reference: ILNK-2024-88821

🏦

Step 4 — Destination Bank Processing

Destination bank receives and credits account

The destination bank receives the transfer, validates the beneficiary IBAN, and credits the account. It sends a confirmation response back to 1LINK which forwards it to the sender bank.

CREDIT applied → Response: SUCCESS sent back to 1LINK

✅

Step 5 — Sender Bank Settlement

Sender account debited, customer notified

Sender bank receives the SUCCESS response, debits the customer's account, and sends an SMS/push notification. The full transaction is recorded in the database.

DB: STATUS = SUCCESS | Debit applied | SMS sent

07 Bill Pay (UBPS) Flow

💡 Bill Payment — How It Works

📱

Step 1 — Bill Inquiry

Customer enters consumer reference number

Customer selects utility company (e.g. LESCO) and enters their consumer reference number. The system sends a bill inquiry request to the utility company's billing system to fetch the outstanding bill.

Bill Inquiry → LESCO API → Returns: Amount Due = PKR 4,200

✅

Step 2 — Customer Confirms

Customer sees bill details and confirms payment

Bill details are displayed — consumer name, bill amount, due date. Customer confirms and authorizes the payment from their account.

🏦

Step 3 — Bank Processes Payment

Bank debits account and sends payment to utility

Bank checks balance, debits the customer's account, and sends the payment to the utility company through UBPS. A payment confirmation number is generated.

UBPS sends payment → Utility confirms receipt → Transaction ID generated

📄

Step 4 — Confirmation

Payment confirmed and receipt generated

Utility company confirms payment received. Customer gets a receipt with a transaction reference number. Bill is marked as paid in the utility company's system.

❌ Common IBFT Failure Codes

Code / Reason	Meaning	L2 Action
Invalid IBAN	Beneficiary IBAN format is wrong or account does not exist	Client side — verify IBAN with beneficiary. Nothing wrong in the system.
Account Inactive	Destination account is closed, dormant, or frozen	Investigate — beneficiary needs to activate their account.
Insufficient Funds	Sender account balance too low for the transfer + charges	Client side — customer needs to top up. Not a system issue.
Daily Limit Exceeded	Customer has hit their daily IBFT transfer limit	Check limits — verify limit in system. Advise customer to try next day.
1LINK Timeout	1LINK did not respond in time — possible connectivity issue	Escalate — check 1LINK connectivity. Multiple customers affected = P1.
Duplicate Transaction	Same transaction reference submitted twice	Check DB — verify if first transaction succeeded. Inform client.

08 Day 4 Lab — Trace an IBFT Transaction

🔬 Lab: Trace an IBFT Transfer End to End

1LINK / IBFT Investigation

Client says: "Customer transferred money but it didn't arrive"

First find the transaction in the sender bank's transfer log and check its status.

SQL — IBFT log

SELECT TXN_ID, SENDER_IBAN, BENEFICIARY_IBAN,
AMOUNT, STATUS, SWITCH_REF, CREATED_AT
FROM IBFT_TRANSACTIONS
WHERE TXN_ID = 'TXN-IBFT-4421';

→ STATUS = PENDING with SWITCH_REF filled = request reached 1LINK but no reply yet

Check if the sender account was debited

Was money taken from the sender? If yes but transfer failed, this is a reconciliation issue.

SQL

SELECT ACCOUNT, TXN_TYPE, AMOUNT,
BALANCE_AFTER, TXN_TIME, REFERENCE
FROM ACCOUNT_LEDGER
WHERE REFERENCE = 'TXN-IBFT-4421';

→ If DEBIT record exists but STATUS = FAILED, money was taken but transfer failed. Escalate immediately — refund needed.

Trace the Bill Pay transaction

Client says: "Bill payment processed but utility company didn't receive it."

SQL — UBPS log

SELECT TXN_ID, UTILITY_CODE, CONSUMER_REF,
BILL_AMOUNT, STATUS, UTILITY_RESPONSE
FROM UBPS_TRANSACTIONS
WHERE TXN_ID = 'TXN-BP-8821';

→ UTILITY_RESPONSE = TIMEOUT means payment reached UBPS but utility company didn't respond. Check utility company status.

Find all failed IBFT transactions in the last hour

Quickly see the scope of any IBFT issue affecting multiple customers.

SQL

SELECT STATUS, COUNT(*) AS TOTAL
FROM IBFT_TRANSACTIONS
WHERE CREATED_AT > NOW() - INTERVAL '1 hour'
GROUP BY STATUS;

→ High FAILED count in last hour = systemic issue. Check 1LINK connectivity and escalate.

09 Real L2 Scenarios

Customer says "I entered my OTP correctly but payment still failed." You check ACS_OTP_ATTEMPTS — all 3 attempts show FAILED even though OTP_ENTERED matches what was sent. You check the timestamp — the OTP was generated 8 minutes ago. It expired after 5 minutes. Customer needs a fresh OTP.

Multiple clients call at the same time reporting 3DS failures. You run the ACS query for AUTH_STATUS = U in the last 15 minutes — you get 400 results. ACS is down. This is a P1. Every online card transaction in the system is failing. Open bridge immediately.

Client says "Customer transferred PKR 50,000 but money not received at destination." You check IBFT_TRANSACTIONS — STATUS = FAILED. Check ACCOUNT_LEDGER — DEBIT record exists. Money left sender but never arrived. Immediate escalation — funds are in transit. Reconciliation team must recover and refund.

Customer paid electricity bill but LESCO still shows outstanding. You check UBPS_TRANSACTIONS — STATUS = SUCCESS, UTILITY_RESPONSE = ACK_RECEIVED. Payment was processed successfully on our side. The issue is with LESCO's internal update delay. You give the customer the transaction ID and advise 24 hours for LESCO to reflect it.

✅ Week 4 · Day 3 & 4 Outcomes

Explain what ACS is and its role in protecting online card payments
Describe the full 3D Secure flow — from checkout to OTP to authentication result
Read ACS status codes — Y, N, U, A, R — and know what each one means for L2
Identify the common ACS breakpoints — OTP not sent, OTP expired, ACS unavailable
Trace a 3DS failure through ACS_AUTH_LOG, ACS_OTP_ATTEMPTS, and ACS_CARD_ENROLLMENT
Explain what IBFT is and the full lifecycle — initiation → TF2.0 → 1LINK → destination → debit
Explain what UBPS is and how bill payments are processed through utility company APIs
Map IBFT failure codes to root causes and the correct L2 response
Trace an IBFT transaction through IBFT_TRANSACTIONS and ACCOUNT_LEDGER
Identify the critical scenario — money debited but transfer failed — and know to escalate immediately

Open ACS &IBFT & Bill Pay