I have done the migration process dwolla.js to dwolla-web.js and found that if we use drop-in component “dwolla-funding-source-create” we will receive an unverified funding source.
Ok, but I can’t understand the logic. Why can we send funds to unverified source from oue DMA, but why can’t we receive the same funds ?
>> Unverified funding sources can only receive funds, not send.
For me it is logical that unverified source means untrusted source. I can understand that you have your own security policy but it looks strange.
In my case we develop loan related solution and for us this logic looks like inverted.
So main question: why can we disburse money from DMA to untrusted source but why can’t we charge repayments from untrusted one to DMA ?
I know that through Plaid integration we will receive verified sources as well. But some of our customers in their business requirements may do not want to buy Plaid account.
Hi @Oliver_Stanford, I’m not sure what you’re referring to with DMA, but this requirement is a NACHA enforced rule that requires ACH originators of debit entries to implement a commercially reasonable method to determine that the account number to be used for a debit entry is for a valid account. I believe the primary reason behind the requirement is to prevent fraudulent transactions from occurring from account takeover scenarios.
So you mean that if we can send money from our verified (by you) MASTER dwolla account to unverified manually added customer dwolla account - it is OK. Possible fraudulent transactions is prevented.
But if we try to receive money to our verified (by you) MASTER dwolla account from unverified manually added customer dwolla account - it is NOT OK. Because possible fraudulent transactions need to be prevented.
Where is the logic ?
For my opinion both cases has to be disabled or enabled with additional checks. But now it looks very strange.
FROM NACHA link >> Financial Institutions (FIs) will be required to validate first-use consumer account numbers when originating consumer debit payments authorized or initiated over an online channel, such as for account opening or loan payment.
I don’t see here that half of operations must be blocked.
Could you please recheck the issue and provide a direct link to NACHA requiremets where it was described? We need to understand how to use integration with Dwolla in general.
Hi @Oliver_Stanford – NACHA only requires verification on the source side to screen WEB debits for fraud (link). This precautionary measure serves to mitigate the risk of debiting bank accounts that may have been fraudulently obtained or are not legitimately associated with the individual signing up and using the account.
While Dwolla does not require bank accounts to be verified in order to receive funds, our Clients have the choice to verify bank accounts on both sides before allowing Customers to transact. This can mitigate the risk of fraudulent activities on both sides of the transaction.