基于API的银行账户信息存储平台

Question

我们正在实现一个门户

• 要求用户提供银行详细信息(路由号码、帐号等)。
• 此数据将通过SFTP发送到另一家将使用银行帐号进行计费的运营商。

在阅读了各种线程之后，我了解到存储支付信息需要一定程度的安全设计。我正在寻找一种替代方案，我们从不存储这些信息，而是进行API调用，从安全平台存储和检索这些数据，然后将数据写入远程的SFTP。

• 这种方法是否降低了我们的风险，假设我们通过合同合法地保护合作伙伴安全地存储信息。
• 这里有一个基于API的平台来提供这种服务吗？有些支付平台提供了处理能力，但我们所需要的只是来自该平台的安全输入和存储。

Answer 1

如果您的系统对敏感帐户数据具有可见性，则您的疏忽可能对任何漏洞或欺诈负责。因此，仅仅通过收集数据，你就会暴露出这些风险。

如果敏感数据“处于静止状态”(无论是在您控制的服务器上还是在与您签订合同的供应商上)持久地存储在您的保管中，而不是仅仅通过您的系统“正在传输”，这些风险就会被放大。

有许多服务将为您存储数据，但它们不会承担任何保管责任，特别是在存储敏感数据所暗示的高度形式上。监护权归你管。

因此，由于您的系统具有可见性，风险仍然存在，您不能期望将该风险转移到其他供应商。因此，在ACH空间中不会有精确地以期望的方式工作的服务。

服务，如Stripe，收集客户支付信息，然后使用该信息请求从客户帐户转账到您的帐户。您可以以最小的风险安全地利用这些服务，因为您从未看到敏感的帐户数据。条纹承担风险，作为交换，采取2-3%的削减.

这一领域的规则在信用卡领域要清楚得多，多年来，PCI在对参与组织进行分类、制定作用和标准、建立审计和合规生态系统以及处理执法等方面发展了相对较高的复杂程度。它并不完美，信用卡欺诈每天都在发生，但它得到了管理，要求和后果更加清晰。

ACH系统，它与PCI的对应物是NACHA，比信用卡系统古老得多，组织得也不太好。这台机器不太成熟。由于不成熟而产生的风险被ACH系统工作的速度所抵消，ACH系统的最低交易时间是天数，而不是信用卡系统可以达到的秒数。但是NACHA仍然期望使用ACH的账单必须有明确的证据来证明发起付款的客户的身份，以及他们对任何特定交易的同意。这些责任从收集这一信息的各方开始。