Securing Your ACH Data in SAP & EC Payroll

Payroll systems need to be secure, we all know that. But recently some additional security requirements have been issued by Nacha - the group that governs electronic payments in the US - for companies originating more than 6 million ACH payments annually. Companies need to be compliant by June 30, 2021. Companies with 2 million or more ACH payments annually need to be compliant by June 30, 2022. The basic concept of the regulation is that bank account numbers at rest must be unreadable.

I am all for making sure employee payroll data remain secure, and these additional rules from Nacha make sense. SAP has issued a couple notes now to guide customers along this process for both the on-premise payroll and EC payroll - see 2993279 and 2914171. They provide some information on where bank account numbers are stored in the standard system and refer customers to the Netweaver Security Guide for information on encrypting database fields. It's a good start, but there is much more to consider. Let's take a look.

First, SAP says that field masking is not required by the Nacha regulation, but I have customers who have interpreted this otherwise so be sure to check with your legal counsel and IT security group to make sure they are on-board. If masking is required, SAP has an add-on component UIM that enables role-based masking. You would need it for the SAP GUI, and maybe UI5 Gateway, UI5 Fiori and Webdynpro ABAP depending on what you have installed and in use for bank account management. I'm in favor of masking account numbers.

Second, encrypting the database fields is not a trivial task so be sure to get your Basis team involved and integrated into your project (yes, this will likely be a project). 

Third - you will probably also want to review your roles to see who can see bank accounts. This will probably also result in some role changes.

Fourth - Many larger clients have a significant number of custom programs and interfaces that will have to be reviewed and potentially modified. For example, maybe you generate the ACH deposit file and store it on the application server before encrypting and sending the bank. It probably also needs to be encrypted when sitting on the application server, before going to the bank. Maybe you outsource part of your payroll to a third-party and you send employee banking to them. Make sure the account numbers are safeguarded along the way.

And finally, this regulation applies not only to SAP/EC Payroll, but anywhere an account number is stored. So check onboarding where you collect the employee direct deposit information. Check your travel & expense process. When customers go live on SAP or EC Payroll, they often keep the old system around for a while, or it is archived off into some custom tables or a database. Account numbers in that data also need to be encrypted - or maybe just eliminate them (I doubt they are needed by now anyway). If you're processing payroll in multiple countries, maybe roll this out to them all so that there is a standard, secure process globally.

So yes, if you are subject ot this regulation it will be a project, unfortunately. Even if you are not subject to the regulation it might be good to review these points and start becoming compliant anyway - no company wants their employee bank account numbers at risk.

up
125 users have voted.

There are 3 Comments

Great post Steve and great timing! We have had this on our radar for 9 months now. We keep asking SAP about a solution with no luck. We'll review the notes to see if it meets our needs.

up
98 users have voted.

Good information to give us a head start. Thanks Steve!

up
115 users have voted.

Add new comment

randomness