How should Balanced update bank account details based on NOC responses?

[jkwade]

Balanced receives Notification of Change (NOC) responses from our ACH vendors as part of the ACH standard. These NOCs sometimes include detailed information about what information has changed. Should Balanced update these bank accounts silently? When we update the resource, should we issue a callback? Should we update the associated fingerprint of that bank account as well? What about other resources that link to the old fingerprint? So many questions...

[jkwade]

Feedback from current Balanced ACH customer:

Our preference would be that if you get an updated account number, you update it silently since we don't store any of that information and update the associated fingerprint of the bank account.

[jkwade]

How PayPal handles this:

After receiving a NOC, PayPal corrects subsequent payments for the affected bank account using the updated information. This means that even if you submit a new payment using the old information, PayPal submits the payment using the updated information.

[msherry]

While I understand that one customer doesn't store this information, we can't assume that no customers do. If we update the bank account number, for instance, do we update the fingerprint attribute and/or last four attributes as well?

• last four: If we do update these, and our customers are using these to differentiate multiple bank accounts to their customers, this number will change, potentially confusing their customers. If we don't update it, it's no longer accurate.
• fingerprint: this is intended to help prevent adding duplicate bank accounts. If we update it, and a user re-adds the old (NOC'd) bank account, this duplicate detection no longer works. If we don't update it, the information is out of date.

[mahmoudimus]

I agree with @msherry - funding instruments, once tokenized, should be immutable for the most part. The only operations that can be performed on them is to invalidate them.

However, I also know that we've discussed before implementing card expiration / updating functionality, so I'm not sure if this falls under the same conversation.

[cieplak]

Should we communicate the NOC via the API to clients who attempt to operate on a bank account that has received a NOC? We could return a 409 conflict, but that would be annoying given that many clients might not handle that exception in their code. Perhaps it would be best to simply communicate out of band to the client and maybe set an expiration on the funding instrument.

[jkwade]

@msherry I have the same concerns about different behavior among different customers. Wasn't trying to make a case, just share a data point. Could there be a key from one BA to another that either Balanced or the MP can create?

The same issue potentially exists for CC resources. The Auto-Updater functionality will replace the existing expiry with a new one. Would this change the fingerprint, effectively creating a new resource?

[msherry]

For CCs, I think we had proposed a clone() method that would allow creating a new resource from an existing one, updating a limited subset of fields like address or expiry date. Since this is initiated client-side, there's no magic going on behind the scenes.

For bank accounts, I'm not sure how to reliably communicate information about changes to our customers -- we have webhooks, but currently no one is required to use them. If we implement NOC updating on the backend and a request is made for the old bank account, should we return something like HTTP 303 - See other, and direct to a new resource with updated information? This still potentially confuses customers of the marketplace in question, but maybe that's their problem?

[jhalickman]

We do not store any of the information, which I thought was best practice when working with the API, so it would make most sense to just update inline. Getting a callback with the updated info and requiring us to create a new account and delete the old one seams unnecessary, especially since we are already using balanced.js to avoid passing bank account numbers through our server.

Just a thought here but what if you created a totally new bank account with the information and returned a 301 when requesting the old one?

[mahmoudimus]

@jhalickman @msherry that's the best way to do it in my opinion, using http semantics to direct to a new resource.

• We'd have to update all our client libraries to understand that redirect.

We can also fire a webhook that asks our customers to update their stored href with the newly tokenized bank account, if we receive it from the bank.

[jhalickman]

That makes sense. Also just for reference you guys 404 on accounts that have received a NOC right now so anything is better then that.

[jhalickman]

@mahmoudimus @msherry one thing that just came up that will cause problems if you create a new account is if there are pending or completed verifications, how will that transfer over to the new account.

We just had a user that added a bank account, his trial deposits went through fine but the bank returned "Incorrect routing/transit number." as the noc_reason (we called the bank, they recently changed their routing number). Balanced is now 404ing on his bank account so he has to re-add his bank account, wait 2 days, re-verify on something that should have been seamlessly fixed by the noc response.

[msherry]

@jhalickman How should this have been "seamlessly fixed"? That's what we're trying to resolve with this issue.

[jhalickman]

if the noc file has the new routing number the bank account should be updated with the correct one.