Who is responsible for unauthorised transactions through a fintech app?

Responsibility for an unauthorised transfer through a fintech app in Pakistan depends on the licensed service provider, contractual and regulatory duties, authentication records and the actual cause of the transfer. The fact that an app displays a successful transaction is not conclusive proof that the customer consented. A customer also does not automatically recover every payment simply by denying authorisation. The Payment Systems and Electronic Fund Transfers Act, 2007, SBP directions, contract and possibly the Prevention of Electronic Crimes Act, 2016 must be examined against the particular incident.

Identify the actual financial institution

A fintech application can be the interface of a bank, an electronic money institution, a payment provider or a technology contractor. Identify who holds funds, executes settlement and contracts with the account holder. A software developer's brand may appear on the screen while a licensed financial institution operates the wallet. Liability should be directed toward the correct legal entity rather than everyone named in marketing material.

Distinguish the type of incident

Possible causes include stolen credentials, SIM replacement fraud, unauthorised account access, employee manipulation, payment system duplication, merchant refund disputes or customer error. The legal analysis differs. A customer who deliberately transferred funds to the wrong recipient may have a recovery problem, while another person whose credentials were compromised may have an authorisation dispute.

What was authorised?

The institution should determine whether an instruction was validly issued by the customer under applicable contract and law. An OTP or login event can provide relevant evidence, but it does not automatically establish informed consent where authentication was compromised. The complete sequence of transactions, devices, messages and confirmation prompts should be preserved. System verification and legal authorisation are not necessarily identical.

SBP supervisory requirements

Licensed banks and electronic money institutions must follow applicable SBP operational, cybersecurity and customer treatment obligations. The precise standard varies with the provider's licence and current circulars. An institution cannot necessarily exclude liability through a broad disclaimer that transfers are always at customer risk. Conversely, liability must be established against a binding duty rather than a general expectation that no fraud should ever occur.

Customer obligations

Users may have contractual duties to protect their login information, never disclose OTPs and promptly report suspected compromises. The provider should evaluate whether those obligations were violated with actual evidence. A customer should avoid delay after receiving a genuine debit alert. Yet an institution should not treat every successful authentication as proof that the customer negligently disclosed credentials.

Immediate incident response

The customer should report the transaction through the official provider channel and ask for the account to be secured. Preserve the case number, time and instructions received. Change relevant credentials and protect linked financial services. The institution should preserve logs and consider lawful measures to prevent further losses. An informal social-media message is not necessarily the equivalent of the provider's required complaint process.

Trace the funds

Identify transaction references, originating account, beneficiary institution and settlement status. Transfer systems may involve several service providers. A receiving institution's assistance may be necessary to investigate or restrict remaining funds within its lawful powers. The provider should not promise reversal if the transfer has become final and third-party rights constrain unilateral recovery.

Device and network evidence

Examine device identifiers, session tokens, IP information, transaction times and recorded authentication challenges where legally accessible. An apparent transaction from an unfamiliar device can be important but not conclusive by itself. The company should preserve raw records and metadata rather than rely solely on a one-page investigator summary. Independent technical review may assist a high-value claim.

SIM-swap fraud

A fraudster may obtain a replacement mobile SIM and receive messages intended for the subscriber. Relevant records can sit with both telecom and financial providers. Determine when the replacement occurred, what identity checks were performed and how the wallet treated the changed SIM. Neither provider's responsibility can be assessed solely from the customer's loss; their distinct contractual and regulatory duties need consideration.

Merchant disputes

An authorised payment for goods never delivered is not necessarily an unauthorised account transfer. The complaint can involve consumer contract performance and applicable chargeback or refund mechanisms. Proper classification matters because available evidence and deadlines can differ. A customer should explain whether the payment was never authorised or the purchased goods or services were unsatisfactory.

Payment duplication

A software fault may cause a transaction to appear twice or debit an incorrect amount. Reconciliation between app ledger, bank account and payment switch can establish whether the same instruction was settled more than once. The institution should investigate technical errors rather than accuse the customer of fraud without a basis. A corrected ledger and actual refund should be documented clearly.

Internal employee misconduct

An employee with privileged access may cause unauthorised transactions or hide audit records. The institution's failure to maintain controls may require separate regulatory review. Dismissing the employee does not necessarily discharge the provider's obligations to customers. Criminal allegations against individuals require proof under the relevant statute and procedural rules.

PECA and criminal law

Unauthorised access, electronic fraud or copying of data can involve PECA provisions where the legal elements are met. The existence of a failed app transfer does not itself prove cybercrime. A formal complaint should identify actual conduct, evidence and suspected offence rather than use criminal process as a shortcut to resolve routine transaction disputes. Separate civil reimbursement claims may still be appropriate.

Complaint and ombudsman routes

The customer should first seek a written investigation outcome from the actual financial institution. SBP complaint arrangements or the Banking Mohtasib may be relevant depending on institution and jurisdiction. Not every wallet-related dispute involves a bank under identical procedures. The complainant should check current regulator guidance before filing with an external forum.

A compromised wallet example

A user's phone loses service unexpectedly and the wallet then transfers money to an unfamiliar account. Investigation should compare telecom SIM events, wallet authentication and beneficiary records. An OTP sent to a fraudulently reissued SIM does not necessarily answer whether the transfer was authorised. The provider should identify the evidence supporting its decision.

Wrong-recipient example

A customer enters a wrong beneficiary number and confirms payment after a displayed warning. The provider may have performed the authorised instruction. Recovery may depend on recipient cooperation or legal processes rather than a claim that the app was hacked. The platform should still investigate any interface error that misdisplayed beneficiary information.

Evidence and remedy

Preserve statements, notices, device evidence, support tickets and any later reimbursement. Loss should be calculated from actual debits and recoveries. A claim for consequential business losses requires separate proof of legal entitlement, causation and amount. No customer should assume a successful complaint automatically produces unlimited damages.

Opinion and recommendation

Unauthorised fintech transfers require an evidence-led determination of authority, technical events and the licensed provider's duties. Report promptly, secure accounts and preserve transaction logs. Seek correction or reimbursement through the appropriate contractual and regulatory route, while reserving criminal allegations for conduct meeting actual penal elements.

Principal authorities: Payment Systems and Electronic Fund Transfers Act, 2007; SBP EMI Regulations, revised June 2023; relevant SBP consumer and cybersecurity instructions; Prevention of Electronic Crimes Act, 2016 as amended; Contract Act, 1872; account agreement.