1. Introduction: Is Your Money Really Safe in a Digital Bank?

Digital banking has transformed how Indonesians manage their money. Customers can transfer funds, pay bills, check account balances, and apply for financial products without visiting a bank branch.

However, greater convenience also introduces cybersecurity risks. Cybercriminals continuously look for weaknesses in banking infrastructure, mobile applications, authentication systems, and human behavior.

A banking cyberattack does not always mean that a hacker has directly broken into a bank’s central system. In some cases, criminals exploit software vulnerabilities. In others, they deceive customers into revealing their credentials, install malware on their devices, or take control of their phone numbers.

These distinctions matter because different attacks require different security measures.

Indonesia has experienced significant banking service disruptions and numerous forms of digital financial fraud. Examining these incidents helps us understand how attacks happen, which security weaknesses may contribute to them, and what banks, developers, and customers can do to reduce the risks.

2. Not Every Banking Cybercrime Is a Bank Hack

Before examining individual cases, we need to distinguish several types of attacks.

2.1 Infrastructure attacks

These attacks target a bank’s IT infrastructure, servers, networks, or internal systems.

Examples include ransomware, exploitation of vulnerable servers, and unauthorized access to internal systems.

The consequences can include service disruptions, data theft, or the compromise of sensitive information.

2.2 Account takeover

An account takeover occurs when an attacker gains unauthorized access to a customer’s banking account.

The attacker might obtain login credentials through phishing, steal an authentication session, compromise a customer’s device, or manipulate account-recovery procedures.

The bank’s core infrastructure might remain secure even while individual customer accounts are compromised.

2.3 Social engineering and phishing

Social engineering exploits human trust rather than relying exclusively on technical vulnerabilities.

An attacker might impersonate a bank employee, send a fraudulent message, or create a fake website that resembles an official banking service.

The objective is to persuade the victim to reveal confidential information or authorize a transaction.

2.4 Insider threats and banking fraud

Not every banking crime involves an external hacker.

Employees or other authorized individuals may abuse their access privileges, manipulate records, or participate in fraudulent transactions.

These cases demonstrate why banks need strong internal controls, separation of duties, and effective audit mechanisms.

Understanding these categories prevents us from incorrectly describing every case of financial fraud as a successful hack of a bank’s central system.

3. Notable Banking Cybersecurity Cases in Indonesia

Case 1: Bank Syariah Indonesia (BSI) Ransomware Attack, May 2023

In May 2023, Bank Syariah Indonesia (BSI) experienced a major disruption to its banking services. LockBit 3.0 reportedly claimed responsibility, alleging that it had stolen approximately 1.5 terabytes of data. These figures were reported claims and should not be treated as independently verified findings.

Attack technique: LockBit affiliates commonly gain access through compromised credentials, phishing, remote-access services, or vulnerable internet-facing applications. They may then escalate privileges, move across networks, steal sensitive data, and encrypt files to disrupt operations. However, the precise entry point and attack techniques used in the BSI incident have not been conclusively established by the sources cited here.

Lessons for developers and banks: Apply security patches promptly, enforce multifactor authentication, restrict privileged access, segment critical systems, monitor suspicious activity, and maintain isolated backups. Developers should enforce server-side authorization, follow least-privilege principles, and secure APIs and services to limit the impact of a breach.

Related sources:

Case 2: Malicious APK and Phishing Attacks in Indonesia (2023)

In January 2023, Indonesia’s Criminal Investigation Agency (Bareskrim Polri) announced the arrest of 13 suspects linked to a fraud scheme involving modified Android application packages (APKs) and phishing links. According to police, the perpetrators sent fake package-tracking applications to victims through WhatsApp, targeting bank customers. Investigators described different roles within the network, including APK developers, social engineers, and individuals responsible for draining accounts and withdrawing money.

Attack technique: The attackers impersonated legitimate package-tracking services to persuade victims to open malicious links or install APK files. The malicious application could facilitate the theft of sensitive information, potentially enabling unauthorized banking transactions. Police reported that the network included people responsible for social engineering and withdrawing funds; however, the public announcement does not establish the precise technical mechanism used to compromise every victim’s account.

Lessons for developers and customers: Customers should never install APK files received from unknown WhatsApp contacts. Developers should minimize sensitive-data exposure, apply strong server-side authorization, protect authentication credentials, and monitor suspicious transactions. Banks should also detect unusual transfers and provide customers with rapid ways to report suspected account compromise.

Related sources:

Case 3: SIM-Swapping Banking Fraud, Indonesia (2020)

In June 2020, Riau Islands Regional Police (Polda Kepri) announced the arrest of three suspects linked to a SIM-swapping syndicate. According to police, the group allegedly took over a victim’s phone number and accessed internet banking, causing losses of approximately Rp415.6 million. One suspect allegedly used a false authorization to report the victim’s phone as lost and reactivate the number under their control.

Attack technique: The suspects allegedly obtained customer information, fraudulently transferred control of the victim’s phone number to a new SIM card, and used the number to facilitate access to internet banking. They then transferred money to accounts associated with the suspects. This case illustrates how weaknesses in SIM replacement procedures and banking authentication can combine to enable account takeover.

Lessons for developers and banks: Do not rely solely on SMS OTPs or phone-number ownership to verify identity. Strengthen account-recovery procedures, require additional verification for sensitive changes, monitor unusual transactions, and notify customers when their registered phone number or device changes.

Related sources:

Case 4: BPR Panca Dana Banking Crime, 2026

On February 23, 2026, Indonesia’s Financial Services Authority (OJK) announced that it had completed its investigation into suspected banking crime at BPR Panca Dana in Depok, West Java. OJK identified three suspects: a former president director, a customer service officer, and the head of the operational department. The allegations included false entries in banking records, unauthorized disbursements involving customer deposits, and fictitious credit facilities. This was a banking crime investigation, not a confirmed cyberattack. (OJK)

Technique and weaknesses: According to OJK, the alleged methods involved manipulating banking records and processing transactions without proper authorization. The case highlights risks associated with insider abuse, inadequate separation of duties, and weaknesses in financial controls. The announcement does not establish that a software bug was involved.

Lessons for developers and banks: Enforce role-based access control, require independent approval for sensitive operations, maintain tamper-resistant audit logs, and monitor unusual account or transaction activity. No employee should be able to initiate, approve, and conceal a high-risk financial transaction without independent oversight.

Related source: OJK — Investigation into Banking Crime at BPR Panca Dana

Case 5. The BCA “Virus” Hoax and Pop-Up Scam (2023)

In July 2023, a viral social media post claimed that a virus warning appearing over BCA Mobile could drain customers’ bank accounts. BCA clarified that its banking application had not been infected and explained that the pop-up was associated with a smartphone detecting potentially harmful applications. BCA also warned customers about unofficial applications and false claims circulating online.

Security risks: The incident highlighted the dangers of misleading security warnings, unofficial or modified applications, malware, and social engineering. Installing applications from untrusted sources can expose sensitive information and banking activity to attackers.

Lessons for customers: Install banking applications only from official app stores, keep devices updated, and verify security warnings through official bank channels.

Lessons for developers and banks: Provide clear security guidance, monitor impersonation and fraud attempts, and help customers distinguish legitimate system alerts from deceptive messages.

Related source: ⁠

4. Common Vulnerabilities Behind Banking Attacks

The cases and techniques described above reveal several categories of weaknesses that banking organizations should address.

It is important to distinguish a vulnerability from an attack technique. A vulnerability is a weakness that can be exploited; an attack technique is the method used to exploit it.

  1. Weak Authentication occurs when banking systems do not adequately verify a user’s identity. Simple passwords, missing multi-factor authentication (MFA), or weak login protections can allow attackers to access accounts using stolen credentials or brute-force attacks.
  2. Broken Access Control happens when a system fails to properly restrict what users can access or do. For example, an attacker may manipulate an account ID in an API request to view another customer’s information or perform unauthorized transactions.
  3. SQL Injection (SQLi) occurs when an application includes untrusted user input in database queries without proper protection. Attackers may exploit this flaw to access, modify, or delete sensitive database records. Parameterized queries and secure database permissions help prevent this vulnerability.
  4. Cross-Site Scripting (XSS) occurs when an application displays untrusted content without properly handling it, allowing malicious scripts to run in a victim’s browser. Depending on the application and its security controls, these scripts may steal sensitive information or perform unauthorized actions.
  5. Insecure APIs. Banking applications often rely on APIs to exchange information between mobile apps, websites, and backend services. Poor authentication, missing authorization checks, excessive data exposure, or inadequate rate limiting can allow attackers to access sensitive information or abuse banking functions.
  6. Insecure Session Management vulnerabilities occur when applications handle login sessions or authentication tokens insecurely. If attackers steal or misuse a valid session token, they may impersonate a legitimate user without knowing the user’s password.
  7. Phishing and Social Engineering exploit human trust rather than relying solely on software vulnerabilities. Attackers may impersonate banks or trusted organizations through fake websites, messages, or phone calls to trick customers into revealing credentials, sharing OTPs, or installing malicious applications.
  8. Malware and Malicious Applications software designed to steal information, monitor activity, or perform unauthorized actions. In banking attacks, malicious applications may imitate legitimate services, capture credentials, or abuse device permissions to compromise customer accounts.
  9. SIM-Swapping Vulnerabilities occurs when an attacker fraudulently takes control of a victim’s phone number by transferring it to another SIM card. If a bank relies heavily on SMS-based one-time passwords (OTPs), the attacker may be able to intercept verification codes and attempt to take over the victim’s account.
  10. Security Misconfiguration occurs when systems, servers, databases, cloud resources, or applications are deployed with insecure settings. Examples include publicly exposed storage, unnecessary services, default credentials, and overly permissive access rules that can expose sensitive banking data.
  11. Unpatched Software and Known Vulnerabilities that remain unpatched can provide attackers with opportunities to compromise servers, applications, or network devices. Attackers may exploit publicly known flaws to gain unauthorized access, execute malicious code, or disrupt banking services.
  12. Insecure Data Storage and Transmission sensitive banking information can be exposed when applications store data without adequate protection or transmit it over insecure connections. Encryption in transit and at rest, proper key management, and minimizing stored sensitive data help reduce the risk of unauthorized disclosure.
  13. Insufficient Transaction Validation vulnerabilities occur when a banking system does not properly verify transaction details on the server side. Attackers may attempt to manipulate payment amounts, recipients, or transaction parameters if the backend relies too heavily on values supplied by the client application.
  14. Insufficient Logging and Monitoring Ican allow suspicious activities to go undetected for too long. Without effective alerts and audit trails, banks may struggle to identify account takeovers, unusual transactions, unauthorized access, or ransomware activity before significant damage occurs.
  15. Insider Threats and Excessive Privileges involve employees or contractors who misuse legitimate access, intentionally or accidentally. Excessive privileges, weak separation of duties, and insufficient oversight can enable unauthorized transactions, customer-data theft, or manipulation of banking records.

Another important distinction is that not every vulnerability is a programming bug.

Some weaknesses arise from system architecture, operational procedures, access policies, authentication design, or human decision-making.

Fixing them requires more than writing better code.

5. How Bank Customers Can Protect Themselves

Customers cannot control a bank’s internal infrastructure, but they can reduce the likelihood that criminals will compromise their accounts or devices.

5.1 Never share your OTP, PIN, or password

A bank employee should not need your password or transaction PIN to help you.

Do not disclose one-time passwords (OTPs), PINs, passwords, or authentication codes to someone who contacts you unexpectedly.

Be particularly suspicious of anyone who claims your account will be blocked unless you provide a code immediately.

An OTP is not merely a number. Depending on the authentication process, it may authorize a sensitive operation.

Avoid accessing banking services through links received in unsolicited SMS messages, emails, or chat messages.

Instead, open the bank’s official application or manually navigate to its verified website.

Be cautious of domains that resemble official banking addresses but contain additional words, misspellings, or unusual domain endings.

A website that looks professional is not necessarily legitimate.

HTTPS alone does not prove that a website belongs to your bank.

5.3 Do not install unknown APK files

Never install an application simply because someone claims it is necessary to receive a refund, verify an account, or resolve a banking problem.

Use official application stores and verify the publisher.

Avoid granting sensitive permissions to applications that have no clear reason to require them, especially accessibility access, notification access, or permission to install other applications.

If you suspect an application is malicious, do not use the potentially compromised device to enter new banking credentials.

5.4 Use strong, unique passwords

Avoid reusing your banking password on email accounts, social media, shopping platforms, or other services.

If one service is compromised, password reuse may allow attackers to access other accounts.

Where supported, use a password manager to generate and store unique passwords.

Protect your primary email account carefully because it may be used to reset passwords for other services.

5.5 Secure your phone number

Protect your SIM card and mobile operator account.

If your phone suddenly loses mobile service unexpectedly, particularly when you have not changed any settings, contact your mobile operator through an official channel.

Unexpected service loss does not necessarily indicate a SIM swap, but it deserves investigation.

Where available, use additional account protections offered by your mobile operator.

5.6 Enable transaction notifications

Turn on banking notifications for transfers, payments, withdrawals, and security changes whenever possible.

Review your transaction history regularly.

The earlier you discover an unauthorized transaction, the sooner you can ask the bank to investigate and attempt to stop further losses.

5.7 Keep your device updated

Install operating system and application security updates promptly.

Remove applications you no longer need, especially those installed from unfamiliar sources.

Avoid rooting or jailbreaking a device used for banking unless you fully understand the associated security implications.

Use a device lock and do not leave your banking application accessible to other people.

5.8 Set sensible transaction limits

If your bank supports daily transfer limits or separate limits for different transaction types, configure them according to your needs.

A lower limit can reduce the amount an attacker may transfer before the problem is detected.

Consider using a separate account for everyday spending and keeping larger savings in an account with fewer transaction capabilities, where practical.

This does not eliminate risk, but it can reduce the financial impact of account compromise.

5.9 Act immediately if you suspect fraud

If you notice an unauthorized transaction:

  1. Contact your bank immediately through its official hotline or application.
  2. Request that affected banking access or payment instruments be blocked where appropriate.
  3. Ask the bank to investigate the transaction and explain its dispute process.
  4. Preserve transaction records, timestamps, messages, suspicious links, and other evidence.
  5. Change compromised credentials using a trusted device.
  6. Report the incident to the appropriate authorities.

In Indonesia, victims can also use the Indonesia Anti-Scam Centre (IASC), established by OJK and participating financial-sector organizations to coordinate responses to financial scams.

Visit the official OJK website to find current information and access the IASC reporting service.

Speed matters because stolen funds may be moved through multiple accounts quickly. Reporting a scam does not guarantee that funds will be recovered, but prompt action can improve the opportunity to block funds before they are transferred further.

6. Important Security Lessons for Software Developers

Banking security must be a core engineering requirement, not an afterthought. Developers must ensure that applications remain secure even when users, devices, or internal systems are compromised.

  1. Never Trust the Frontend

Frontend validation is for usability, not security. The backend must independently validate requests, verify permissions, and enforce all financial rules.

  1. Prevent Broken Access Control (BOLA)

Verify authorization for every sensitive resource and operation. Users must only access accounts and data they are permitted to access. Random IDs alone do not provide security.

  1. Strengthen Authentication

Use strong authentication and consider phishing-resistant methods, such as passkeys, for sensitive operations. Apply additional verification when users change account details, register devices, or make high-risk transactions.

  1. Do Not Rely Solely on SMS OTPs

SMS OTPs can be vulnerable to phishing and SIM swapping. Use appropriate authentication methods and ensure transaction confirmation is securely linked to the intended operation.

  1. Prevent Replay Attacks and Duplicate Transactions

Network failures and retries can cause duplicate payments. Use properly scoped idempotency keys, reliable database transactions, and transaction-state validation to prevent repeated execution.

  1. Enforce Business Rules on the Backend

Validate balances, transaction limits, beneficiary eligibility, and transaction status on the server. Use controlled state transitions for sensitive financial operations.

  1. Protect Secrets and Sensitive Data

Never expose credentials, API keys, or authentication tokens in source code or logs. Use secure secret management, restrict access, and redact sensitive information from logs.

  1. Secure APIs

Implement strong authentication, authorization, input validation, rate limiting, secure token management, and encryption in transit. Avoid exposing sensitive information through API responses or error messages.

  1. Prepare for Infrastructure Compromise

Apply least privilege, network segmentation, timely patching, multi-factor authentication, protected backups, and tested recovery procedures to limit the impact of attacks such as ransomware.

  1. Implement Security Monitoring

Monitor suspicious logins, device changes, unusual transfers, repeated failures, and unexpected administrative activity. Use actionable alerts to detect and respond to threats quickly.

  1. Test Security Continuously

Integrate threat modeling, automated security scans, dependency checks, API authorization tests, and penetration testing into the development lifecycle. Pay particular attention to business logic, account recovery, and administrative workflows.

Back to the main page