1

We are implementing a portal that will

  • Require user to provide the bank details (routing number, account number etc).
  • This data will be sent through SFTP to another carrier that will use the bank account number for billing.

Having read various threads here I have learned that storing payment information requires a certain level of secure design. I'm looking for an alternative where we never store this information but instead make an API call to store and retrieve this data from a secure platform and then write the data to remote SFTP.

  • Does this approach reduce our risk assuming we are legally covered through contract that the partner stores information securely.
  • This there an API based platform that provides this service? There are payment platforms that provide the processing capability but all we need is secure input and storage from the platform.
4
  • I would get in touch with a compliance firm and have them look at what the implications of something like this would be. I for one would be afraid of running afoul of SOX compliance. Aug 9, 2016 at 20:59
  • Have you considered tokens vs actual account data? Aug 9, 2016 at 21:08
  • @coffeethulhu, we'll off course get our in-house compliance expert weigh in on the approach. I was just looking for possible solution alternatives to propose.
    – user9445
    Aug 9, 2016 at 22:22
  • @ShaneAndrie, We will have to accept account data and send it to the partner using SFTP. Their EDI formats are defined so we don't have much flexibility there. I'm not sure how tokens will help since we don't need to save, retrieve or use account data once it is sent to the partner.
    – user9445
    Aug 9, 2016 at 22:27

1 Answer 1

0

If your systems have visibility to the sensitive account data, your negligence could be responsible for any breach or fraud. So by merely collecting the data, you expose yourself to these risks.

These risks are magnified if the sensitive data is durably stored "at rest" in your custody- whether on servers you control or at a provider you contract with- rather than just passing through your systems "in transit."

There are plenty of services that will store data for you, but they will not take any custodial responsibility, particularly in the heightened form that storage of sensitive data implies. Custody remains with you.

So- because your systems have visibility, risk remains with you and you cannot expect to shift that risk onto another provider. Therefore there will not be services that work in precisely the desired fashion in the ACH space.

Services, like Stripe, collect customer payment information and then use that information to request transfers of money from customer accounts to your account. You can safely utilize these services with minimal risk because you never see the sensitive account data. Stripe bears the risk, in exchange for taking a 2-3% cut.

The rules in this arena are much clearer in the credit card domain, where PCI has over the years developed a relatively high degree of sophistication for classifying participating organizations, developing roles and standards, building an audit and compliance ecosystem, and handling enforcement. It is not perfect, and credit card fraud occurs every day, but it is managed and the requirements and consequences are much clearer.

The ACH system, whose counterpart to PCI is NACHA, is much older and arguably less well organized than the credit card system. The machinery is much less mature. This risks that arise from the lack of maturity are offset by the pace at which the ACH system works, in which the minimum transaction time is days rather than the seconds that can be achieved in the credit card system. But NACHA still expects that billers utilizing ACH must have clear evidence both of the identity of the customer initiating the payment and of their assent to any particular transaction. These responsibilities begin with the parties who collect this information.

2
  • thanks for the answer. We discussed this with out compliance group and have decided to save the bank information in an encrypted for when it is on persistent storage.
    – user9445
    Aug 12, 2016 at 21:00
  • Sure- FWIW it may be helpful to follow PCI recommendations on encrypted storage even though NACHA doesn't require it. The recommendations mostly revolve around key management, which can be tricky. Data encrypting keys have to be stored separate from the data and protected by key encrypting keys, which need to be in custody of a split knowledge regime. Integrating key management with backups can also be tricky, because of the risk no reason to reinvent the wheel. Good luck. Aug 13, 2016 at 19:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .