HBL Credit Card Unauthorized Transactions Without OTP

 

My HBL card received repeated OPENAI charges within minutes, but no OTP reached me. I traced what the records actually prove

 Multiple unrecognized OPENAI transactions reached my HBL credit card within minutes on 28 August 2026. My case raises questions about online card authentication, 3-D Secure and when HBL requires an OTP.

At 4:53 p.m. on 28 August, I was at home in Karachi when my phone began showing HBL credit-card alerts. An OPENAI transaction for $10 appeared first. A charge for $18 followed, and within minutes I began receiving repeated $28 transaction alerts. I had initiated none of them.

One $28 attempt failed. Several others succeeded. By about 5:02 p.m., the HBL alerts showed successful authorizations totalling $158, although an authorization alert does not by itself establish final posting or settlement.

I use ChatGPT Plus, which made the merchant name OPENAI initially look familiar. My billing records soon created a problem with that explanation. OpenAI had already charged my legitimate $20 monthly ChatGPT Plus subscription on 17 August.

My first thought was predictable: someone had hacked my card. But the alerts could not tell me that. They showed transactions reaching my card account, not how the payment credentials had reached the merchant.

My evidence establishes unrecognized transactions against my HBL credit card. It does not establish an HBL network breach or misconduct by OpenAI.

HBL Credit Card Unauthorized Transactions: What My Records Show

I started with reconciliation rather than speculation.

My ChatGPT billing history showed the normal Plus subscription at $20. The August payment appeared on 17 August, eleven days before the disputed transactions. None of the $10, $18 or $28 amounts appeared in the ChatGPT subscription history visible to me.

I then checked the OpenAI API billing account associated with my login. It showed a free-trial account with $0 credit remaining and invited me to add payment details. Nothing visible on that account explained the transaction cluster.

OpenAI advises customers who find an unrecognized charge to check their invoices before escalating the matter. Its current guidance also recommends contacting the card issuer immediately when a customer believes a transaction is unauthorized.

My records produced the following comparison:

Record	What I found
ChatGPT Plus	$20 paid on 17 August 2026
HBL alerts	$10, $18 and repeated $28 OPENAI transactions on 28 August
Successful alerts identified	$158 in total
Declined attempt	One additional $28 transaction
OpenAI API page checked	Free trial with $0 credit remaining
Immediate action	I blocked my HBL credit card

I cannot establish from those records whether every successful authorization subsequently cleared. That distinction matters because authorization and final settlement represent different stages of a card transaction.

Still, one fact stood out. The OPENAI amounts appearing through HBL did not reconcile with the OpenAI billing information visible in the accounts I checked.

Why an Online Transaction Does Not Prove HBL Was Hacked

People often use the word "hacked" as soon as an unfamiliar card transaction appears. I understand the reaction. I had it myself.

Yet a criminal does not normally need to penetrate a bank's internal card network to attempt an internet purchase. Compromised payment credentials can enter the fraud chain elsewhere, after which someone can attempt a card-not-present transaction through a merchant.

No physical card needs to enter a terminal.

The merchant sends a payment request through its payment infrastructure. The transaction eventually reaches the issuing bank for an authorization decision, but the brief alert on my phone does not reveal the complete route or authentication data behind that request.

For an HBL customer, the distinction becomes particularly important because HBL publishes specific information about its 3-D Secure service.

HBL says its credit cards support 3-D Secure for internet transactions. Its published material states that customers receive a six-digit OTP when they transact on a 3-D Secure-enabled website through HBL's described authentication process.

HBL's FAQ then makes another point that deserves attention. It says customers will receive an OTP only for internet transactions on 3-D Secure-enabled websites.

That leaves an important question in my case.

Were the disputed OPENAI transactions processed through HBL's 3-D Secure authentication flow at all?

I cannot answer that from an email alert.

HBL can.

Why I Am Not Assuming a Frictionless HBL Transaction

Modern card authentication makes the OTP issue more complicated.

Visa's current EMV 3-D Secure architecture supports risk-based authentication. Under a frictionless flow, an issuer can authenticate a low-risk transaction without requiring the cardholder to complete an additional challenge. A transaction assessed differently may trigger an authentication challenge.

That general Visa architecture does not prove what happened to my HBL card.

HBL's published credit-card documentation describes its own 3-D Secure process differently. HBL says that when a cardholder makes an online payment on a 3-D Secure service website, the cardholder enters a unique six-digit OTP sent through the registered communication channel.

I therefore cannot simply say that Visa's frictionless authentication explains why I received no OTP.

The better question concerns classification. Did the disputed transactions enter HBL's 3-D Secure process, or did they reach HBL through another e-commerce authorization route?

Stored payment credentials create another possibility that a customer alert cannot resolve. HBL's own terms contemplate transactions authorized in advance to recur at substantially regular intervals.

A familiar subscription illustrates the principle. I do not normally enter my complete credit-card information every month when an established digital subscription renews.

None of that establishes what happened on 28 August.

It does show why "I received no OTP" and "HBL was hacked" are not equivalent statements.

What Bothers Me About the Transaction Sequence

I spend my working day around cross-border payment operations, so sequencing catches my eye.

The timing bothered me more than the individual amounts.

The first disputed alerts arrived around 4:53 p.m. Another authorization appeared around 4:54. Further activity followed near 5:00 p.m., with another $28 transaction appearing at approximately 5:02.

One $28 attempt was declined amid the cluster.

Several transactions carrying the OPENAI merchant descriptor had therefore reached the same HBL credit card within roughly ten minutes. Some repeated exactly the same $28 amount.

I cannot infer why HBL approved particular authorizations. A decline can occur for reasons unrelated to suspected fraud, including available-credit limits or an issuer's authorization controls. I therefore cannot infer from the declined $28 attempt that HBL had identified fraudulent activity.

Yet the sequence raises a fair banking question.

How did HBL's authorization and fraud-control systems assess repeated international e-commerce transactions carrying the same merchant descriptor within minutes?

Card networks already support real-time risk assessment. Visa, for example, describes authentication systems that evaluate transaction information and behavioural signals before deciding whether additional verification is appropriate.

The customer does not see that analysis.

I saw only the emails.

What I Want HBL to Establish

A generic response saying that these were "online transactions" would not answer the main question.

I want HBL to establish whether each disputed transaction went through 3-D Secure or entered as non-3DS e-commerce. If authentication occurred, I also want to know what authentication status HBL received.

The bank can investigate whether stored-credential indicators accompanied relevant authorizations. Where applicable, it can also determine whether the merchant presented a transaction under a recurring or merchant-initiated arrangement.

The authorization chronology matters too.

Why did several transactions carrying the same merchant descriptor and repeated amounts receive authorization within minutes, while another $28 attempt was declined?

I also want HBL to distinguish authorizations from transactions that finally cleared. An alert may show that an issuer approved an authorization request, while the subsequent clearing record establishes whether the transaction actually posted.

Those details would tell me far more than the word OPENAI on an email.

The Lesson for HBL Credit Card Users in Pakistan

In Karachi, as in much of Pakistan, many cardholders have learned to associate internet-card security with one small event: an OTP arrives on the phone.

No OTP feels wrong.

HBL's own material helps explain why that expectation exists. The bank promotes 3-D Secure as an added protection for supported online transactions and describes OTP verification as part of that process.

My case taught me not to stop at the OTP question.

When the alerts began, I blocked my credit card. I also preserved the HBL emails because they recorded the amounts and transaction times.

I then checked the merchant records.

That step mattered. The legitimate $20 ChatGPT subscription appeared separately in my OpenAI transaction history, while the unusual HBL amounts did not appear in the subscription history visible to me.

OpenAI recommends essentially the same reconciliation process. Its current guidance tells customers to check invoices first and contact their bank promptly when they believe a charge is unauthorized.

OpenAI guidance on unrecognized charges

For an HBL customer facing the same problem, the bank statement becomes important after the initial alerts. It can show which authorizations eventually posted.

Screenshots deserve care too.

I would remove card identifiers and personal account information before publishing transaction evidence online. A consumer can document a dispute without exposing unnecessary financial information.

Language matters just as much.

I describe my August 28 transactions as unrecognized or unauthorized transactions under dispute. Calling them proof of an HBL security breach would require evidence that I do not possess.

The Information Still Missing From My HBL Alerts

I began with a phone vibrating at home in Karachi and a merchant name I recognized.

The amounts did not make sense.

Blocking the card limited my immediate exposure, but it could not reconstruct the payment path. My legitimate $20 ChatGPT subscription and the disputed August 28 transaction cluster remain separate in the records available to me.

Behind the short merchant descriptor OPENAI sits a much richer authorization record. HBL can examine information that never appears in a customer email, while the merchant side can identify the payment activity associated with the disputed charges.

I am waiting for those records to meet.

Until then, I have a sequence without an origin I can verify. The alerts tell me what reached my card. They do not yet tell me who sent it.

---

• AI Transparency Statement: "This analysis was drafted under editorial direction with AI technical assistance, then verified and edited by Munaeem Jamal."