Wires Integration

November 21, 2024

Prompt
Assume I'm an engineer on the banking team and we are about to integrate with a new technical system,
can you prepare a 15-20 minute presentation explaining that system, how we would integrate with it, and
what the potential issues are going to be. This should be something that you have direct experience with,
ideally banking related (ACH, wires, card payments, etc) if you don't have experience with these, any
technical system is fine.

You can think of this as a product manager discussion focusing on processes plus technical needs,
resourcing, and limitations. We don't have a preferred format but typically a small number of slides work
best. What Connor will be looking for here is that you can show a solid technical understanding of a banking
system, can identify which parts of building it will tricky or need special consideration, and imagining he is
an engineer on the team, that you can answer questions he might have about how it works and discuss
options how you and him might want to handle some of those tricky situations.
 Opportunity Tree and Goals
Customer
Customer Problems
Problems Company Goals Product Discovery
● I want to be able to send ● Acquire more ICP ● When selecting a business bank
payments faster customers MoM account, the ICP rates the ability to
● I want to be able to pay my ● Improve customer send wires as a 4 or higher on a scale of
vendors / contractors based on experience and reduce 1 to 5
their preferred payment OPEX ● The ICP demonstrates a monthly
method projected future use of wires of 83%
● [EJTBD] I want to feel certainty ● The ICP requires domestic wire usage
of payment acceptance by 4X compared to International wires.
● 80% of business owners expect to send
wires mostly up to $10,000
● The ICP uses wires because its fast and
the recipient asks to be paid that way.

Possible Solution: Domestic wire solution with fast follow of RTP/Fednow

Proposal: Build wires via Plaid Transfer Product
Why Plaid Transfer?

● Faster to market with a single FBO / single external Ledger (easier reconciliation build)
● Approved vendor, no additional Bank approval required
● Single unified API to do both wires and RTP/FedNow
● Solid bank partner: Cross River Bank
● No need for onboarding all of our customers (KYC/KYB) and management of payees on another system

Integration will require the following:

Internal Services:
Plaid Transfer: ● Authentication
● transfer/authorization/create ● Fraud and Risk
● transfer/authorization/cancel ● Counterparties
● transfer/create ● Transaction Management / Ledger
● transfer/cancel ● Internal Tools and Slack
● transfer/ledger/deposit ● Mailer
● transfer/ledger/distribute ● Limits
● transfer/ledger/get ● New Wire service to call all Plaid flows and money
● transfer/ledger/withdraw movement
Flow with Transfer Creation
Counterparty Creation Things to consider:
- There will be always the risk of an outdated Fed directory
of wire eligible routing numbers. As those get updated, we
will need crons to make sure we check our wire
Counterpart Fed
counterparties and inform customers if there is a routing
ies Directory number no longer eligible that once was. Need to update
Wr
payee status to ‘error’.
ite
an
d sto
- If we do not have a direct API to the Fed to download the
re list or constantly update it via a script download / upload,
va
lue
it will have to be managed manually
Customer goes into Customer inputs the - In the event that our mailer service or segment /
app and elects to various information Success rudderstack event does not trigger, we do not need a retry
add a payee required mechanism here for the first iteration because it will
appear when we load the payees in their payment
experience.
- The counterparty requirements should match all of Plaids
Mailer /
Failure Notification to avoid any impacts of rejections.
Service - Given we manage everything in house, we do not need to
worry about data quality on Plaid (statuses, etc.)
Inform customer of error on
FE. Examples:
Email or
Non wire routing number
Notification sent
Incorrect Account length
to customer or the
payee
 Flow with Transfer Creation Things to consider:
- There will be instances where we will need retry mechanisms
built where the failure was due to funds_secured. If the funds
are no longer there we should deny for NSF. If funds are there,
Use transfer/ledger/get to sync if
the retry mechanism should exist until someone manually
needed or fall back to last transaction
Create a Transfer running balance
rejects or a cancellation is required.
- There will be instances where the Plaid Ledger shows
insufficient balance and we will need to fund CRB on a same
day wire to our respective account / routing #. OR once a
threshold is hit we can use transfer/ledger/deposit. Preference
Plaid
ass Limits Ledger - would be wires, because these funds are on hold for 3 business
orp
or y Wires days.
err te an
h row upda alues - All customer comms would be based on the various status
T d v
an amic Slack updates and the respective meta of description / reason.
dy n Service
e of
ba lanc e is
Customer goes ning re ther ll
run u
t last ens for a
into app and G e
ctio
n o in Plaid
t IF ALL PASSES MOVE ON, SEND SLACK WITH Transaction
sa d s REMAINING BALANCE. IF NO, SAY WIRE TRANSFERS Ledger
enters amount tran ent fun ions
ci sact NOT AVAILABLE AND THROW SLACK ALERT
suffi tran

Use internal API to secure Hit transfer/authorization Ensure transaction debit is

Customer request
the funds and log an and transfer/create if first posted, mapped, and an
captured with a
Risk event for funds_secured. If successful and approved entity ID exists to map to
pending status Engine that fails, keep in status. and update to sent. recon. See recon flow.

If there is a rejection,
Update to If manual_review is approved, the ledger move to rejected
Transaction
Wire
manual_review or balance check has to happen again. If
Transfers Ledger
declined based on insufficient, keep in manual review and log
outcome error in Slack. If sufficient, approve. We Return funds, mark
also need to check DDA balance and funds_returned event and
Tools
approve or decline for NSF. post new transaction.
Service
 Recon Flow Things to consider:
- If we ever get a webhook for a transfer_ID we do not have
in our Plaid Ledger - Wires, we throw a slack error to
determine the issue.
- Every single debit and credit needs to map to a specific
transfer_id and every event needs to map to its own
Plaid unique ID. So the transfer_ID has a one to many
Ledger -
Wires
relationship to all the various event_IDs. Anytime funds are
secured, funds can only be returned for rejection or
return.

Everytime there is a successful When the debit occurs, and we get a

transaction we accept, we need webhook for a specific transfer_id, we If we get any webhook for a return of a wire transfer,
to ensure its posted to our should post the respective debit and we should do the following:
customer account and an internal update the balance of our settlement
Plaid shadow ledger. account and the ledger. 1. Post to Plaid Ledger as a transaction with
last running balance
2. Update balance in settlement accounts
3. Update status of wire transfer ID as
returned with a funds_returned.
Settlement 4. Hit transfer/ledger/withdraw to our
Accounts settlement account internally
5. Once it hits our internal settlement account,
Wire return the funds to the customer.
Transfers
Transaction
Ledger Post the credit back to the
customer, map the Tools
Service
transaction to the original
transfer_id
Q&A and Notes