Hackers have a variety of options in the modern business environment for obtaining money unlawfully. People are constantly looking for ways to steal money and assets from companies. One method that financial hacks take place is when hackers use email correspondence to pose as vendors or customers’ or customers’ legitimate bank accounts in order to solicit payments.

I’ll now go over the specifically designed SAP system to find fraudulent bank accounts.

Building a control to avoid paying into phoney bank accounts involves the following steps:

Step -1:

To include the bank accounts that were both suspected of and found to be fraud bank accounts, create a custom table. The following columns may be included in the custom table used to enter the bogus bank account:

  • Continent Code
  • Account Number
  • Number of a bank account
  • Bank Name
  • IBAN Reference
  • produced by (User id who created the record in this table)
  • produced on

Step – 2:

Include any bogus bank accounts that the company has discovered in the table that was prepared in Step #1.

Step – 3:

Create a unique User Exit through a Function Class in an ABAP programme, then add it to the “Save” function for vendor or customer accounts. The save method gives an error message if this vendor’s or customer’s bank account matches the bank account in the custom table in step #1 above.

Then, a central block will be applied to all company codes to block that vendor’s or customer’s account.

Step – 4:

In step #1 above, create a custom programme to check the bank accounts of vendors (and consumers, if necessary), and compare them to the bank accounts in the custom table.

Step – 5:

The custom software will run as a scheduled job in step #4. The application uses the custom function to send an email containing a list of the vendors who have been given access to a fake bank account. The software compares the records in table LFBK for bank account comparison and table TIBAN for IBAN comparison to the bank account records in the custom table prepared in step #1 above. Using XK05 in the field LFA1-SPERR or FD05, it blocks the vendors with bogus bank numbers if it discovers any matching records. Similar to this, the software compares the data in table KNBK for bank account comparison with the bank accounts in the custom table generated in step #1 above. The consumers with bogus bank numbers are blocked using FD05 in field KNA1-SPERR if it discovers any matching records.

Applying a vendor’s central posting block:

All company codes in XK05 will be affected by the posting block to the vendor.

Using a customer’s central posting block:

Under all business codes in FD05, the posting block to the customer will be used.

S4 also has features that is comparable.

Before adding or amending a bank account under a vendor or customer account, the business team in charge of doing so must double-check the information with the appropriate contact person of the vendor or customer concerned by email or phone. They must add that bank account to the fraud bank account table if they discover that the bank account change was not initiated by the related vendor or customer. This stops any upcoming payments to this account.