Investment infrastructure
Keeping an investment journey connected across services.
Connecting investor accounts, bank verification, purchase orders, mandates and reports through a shared backend.
- My contribution
- Backend & integration engineering
- Context
- Investor accounts & transactions
- My responsibility
- Worked on backend workflows connecting investor accounts with investment-provider services.
- The key decision
- Keep local account and order references alongside provider identifiers and process bank verification through a queue.
- What changed
- Investor workflows connected across verification, purchase orders, recurring plans and account reports.
The problem & my responsibilities
An investment journey crosses several systems before an order is usable: investor details, a bank account, verification, a purchase request and its payment or mandate. Each provider operation has its own identifier and state. The product needs to keep those relationships attached to the correct investor.
My work covers backend services for investment accounts, bank verification, purchase orders and recurring investment plans, along with investor-report integration. I focused on connecting provider responses with the application’s account and order records.
Constraints that shaped the work
- Provider identifiers differ from local account and order identifiers
- Verification and order status can change after the initiating request
- Basket purchases expand into multiple fund orders
- Reports and bank accounts belong to specific investors
How the system fits together
- 01OnboardConnect investor details, investment accounts and bank records
- 02VerifyQueue bank verification and save its status and provider response
- 03TransactCreate purchase orders or recurring plans with local and provider references
- 04TrackUpdate order state and retrieve reports for the owning investor
The consequential decisions
| Decision | Choice | Alternative | Trade-off |
|---|---|---|---|
| Provider integration | Local records linked to provider identifiers | Pass provider responses straight through without application records | Orders and accounts remain traceable through local user relationships, provider references and saved responses. That context helps connect later status updates to the originating request. |
| Bank verification | Queued verification with stored status | Make account creation wait for the entire verification workflow | Verification can run separately from account creation, with bounded retry settings and recorded failure details. A saved bank record and a verified bank record remain different states. |
| Investment baskets | Expand allocations into individual provider orders | Represent a multi-fund basket as one opaque transaction | Per-fund orders preserve fund identifiers, amounts and responses. The product must then account for each order’s state when presenting the basket. |
| Investor reports | Check account ownership before requesting reports | Trust an investment-account identifier supplied by the client | Holdings, capital gains and returns reports are requested in the authenticated investor’s account context. |
Where the work got difficult
Connect asynchronous state changes
Provider acceptance, payment confirmation and order completion happen at different points. The application keeps provider references and order status so those transitions can be followed without treating the initial request as the entire journey.
Handle recurring-plan changes
A recurring investment includes plan settings, installments and mandate relationships. Updating or cancelling a plan needs to address the provider operation and the application’s view of that plan.
Operating considerations
Partial failures
A basket can involve several provider calls. Individual responses and failures need to remain visible so a retry or support action can target the affected order.
Sensitive account data
Investor, bank and identity data require scoped access and deliberate handling across storage, provider requests and operational logs.
State reconciliation
Provider status and local records can diverge after a timeout or delayed update. Stable references are essential for investigating the actual state before taking another action.
Outcomes & lessons
The backend connects investor-account services with queued bank verification, purchase and basket orders, recurring-plan operations and investor reports. Local records preserve the relationships needed to follow these workflows across provider boundaries.
Integration work becomes product work when the user needs one coherent journey across several independently changing systems.