Momento built a mobile banking and remittance product for workers in the United States and their families in Mexico and El Salvador between 2020 and 2022. The worker received a US account and debit card, with direct deposit and family remittances to send home. A family member abroad received the money on a locally issued card.
Momento developed the US and Latin American application services and ran the operating model around them: bank counterparties, payroll and FX arrangements, local card processors, compliance reviewers and customer support. The application handled customer journeys and provider events. Financial institutions and processors controlled accounts and money movement, and funding, confirmation and reconciliation responsibilities connected the two, country by country.
01 / The problem
A payment has more than one state
A customer’s instruction, a provider’s account status, a bank movement and a recipient’s card credit describe different events. A mobile confirmation alone does not show that the financial path is complete. The design therefore needed both application visibility and financial reconciliation.
The operating constraints were country-specific: separate sender and recipient relationships, provider eligibility, card manufacture, Mexico FX and prefunding, and El Salvador dollar funding. Changes in any of these dependencies could affect the service even while the app and local processor were available.
02 / Inside the system
Application services and financial authority
The US application is a React Native app with Expo release tooling and Node.js query, transaction and webhook services behind an Nginx ingress on Google Cloud Kubernetes. Query services expose application information; transaction services carry instructions; webhook services receive changes from external systems. SQL Server/Cloud SQL holds application data and MongoDB holds transaction logs.
The Latin American application uses React Native, Nest.js services and country-labeled app and webhook components connected to local card processing. The US production design specifies autoscaling nodes; the Latin American design specifies one application node. Shared product identity did not make their deployment layouts identical.
Application records and logs support the journey and investigation. Bank account books, clearing movements and local processor balances remain financial reference points for reconciliation. The architecture does not make the application database the authority for funds held by another institution.
- Mobile and release
- React Native, Expo release tooling and country-specific applications in the 2022 architecture.
- Application services
- US Node.js query/transaction/webhook services; Latin American Nest.js and country-labeled webhook services.
- Data and infrastructure
- Nginx, Google Cloud Kubernetes, SQL Server/Cloud SQL, US MongoDB transaction logs and Cloud Storage.
- Delivery
- GitHub Actions and containerized backend delivery, with Expo mobile release tooling.
03 / Inside the system
From a customer instruction to recipient funding
The Mexico operating flow starts with an FX quote. The sender confirms the US amount, exchange rate and recipient amount using an OTP. The flow then makes an internal transfer between the consumer’s US account and the relevant funding relationship, an instruction to load the companion card in pesos, and periodic dollar settlement with an operations file.
Treasury work connects the two currencies: a Mexican banking relationship supplies pesos, funds are transferred to the processor’s loading account, and confirmation allows the processor to identify available funding. Operations reconcile the bank movement, FX operations and card loading rather than treating one application event as the entire transfer.
The El Salvador route is separate and uses dollar funding through the local processor. These are workflow dependencies, with human and provider roles carrying the decisions.
A worked example
Example: a US-to-Mexico family payment
Example with invented data.
01 / InputsSender and companion are eligible
Assume an eligible US account, an enrolled Mexican recipient and an assigned local card. The sender requests USD 100. Account-provider eligibility and recipient-card readiness are separate prerequisites.
02 / ConfirmConfirm the quote and instruction
Assume a quoted rate of MXN 17.00 per USD and no fee: USD 100 corresponds to MXN 1,700. The sender confirms the US amount, exchange rate and recipient amount using the OTP step in the operating flow.
03 / FundingConnect bank movement and local funding
The design requires an internal US account movement and a companion-card loading instruction. Treasury’s periodic dollar settlement and peso prefunding must support the recipient amount. An app instruction is not proof that bank settlement or local funding occurred.
04 / ReconcileCompare the financial references
Operations associate the bank movement and settlement file with the FX amount and processor credit. A shared example label such as EXAMPLE-01 stands for the association in this walkthrough.
05 / ExceptionHold the conclusion when a dependency is missing
If the account provider changes eligibility, clearing access is blocked, or local funding is unconfirmed, the walkthrough cannot conclude that the remittance completed. The responsible provider and operations team must resolve the specific dependency before a reconciled financial outcome can be shown.
04 / Inside the system
When provider state changes
Eligibility comes from the account provider and can change after onboarding. In March 2022 the provider rescored accounts, moving some from send-and-receive eligibility to unverified. The lack of a video-identification route became an operating problem, because the original product policy had excluded that group.
Local card operations also required a response path for risk alerts, lost cards and disputes. The Mexico operating flow describes review of unusual transactions, customer contact and card locking when the customer could not be reached or did not recognize the transaction. App support and processor support needed a clear handoff.
05 / Inside the system
Choices that exposed the dependencies
The program’s consequential choices concerned authority, eligibility and operating complexity: who supports which problem, who is eligible, and how much capacity each environment gets. Each exposed a dependency on another organization.
- Decision 01
Support follows financial responsibility
Allocate financial and regulatory complaints to the banking provider, with application and general support handled by Momento.
The signed requirements aligned escalation with the organization responsible for the underlying service.
Trade-off. A unified customer journey still required reliable handoffs and follow-up between organizations.
- Decision 02
Eligibility without a video route
Originally exclude low-score applicants instead of implementing a video-identification path for them.
The product did not serve low-score applicants.
Trade-off. Provider rescoring could move existing accounts into the excluded category, leaving a gap in verification and affecting direct deposit.
- Decision 03
Environment capacity differed
Run lighter development and test environments and a US production design with autoscaling and multi-zone SQL.
The architecture allocated different capacity to development and serving environments.
Trade-off. The US layout did not carry over to the Latin American one-node application design.
06 / Inside the system
Test each service at its own layer
In Mexico, the prepaid card configuration was tested for connectivity, web-service delivery and training with the local processor. The later remittance and card configuration was a separate scope with its own processor setup.
In El Salvador, the local processor set up its processing services and trained the team in November 2021.
A complete remittance closes when the US source movement, FX execution where applicable, settlement or prefunding, and recipient credit match. That reconciliation is the operating test in each country.
- What did each country’s processor tests cover?
- Card and processing scope, connectivity, web-service delivery and training. Bank and settlement dependencies were tracked separately.
- What closes a complete remittance?
- Matched evidence for source movement, FX where applicable, settlement/prefunding and recipient credit, with the corresponding provider acceptance.
- What happened when the provider changed an account’s eligibility?
- The account could move from send-and-receive eligibility to unverified. Without a video-identification route, the customer needed a revised verification journey, and direct deposit could be affected.
07 / Inside the system
Deliver through functional and institutional handoffs
Product and operations defined the customer journey, eligibility assumptions and support process. Mobile/backend engineers, UX, QA and delivery collaborators developed and prepared the application services. Provider project managers coordinated local processing, training and acceptance testing. Local processor training covered disputes, fraud, operating tools and finance.
Banking, payroll, FX, fraud and card specialists supplied different financial capabilities. Compliance reviewers addressed onboarding and operating controls. Written policies and contract allocations gave these functions a responsibility framework; each country still needed its own operating setup and provider testing.
The people around the workflow.
- Product and operations
- Eligibility, customer journeys, support routing, country operating flows and scope coordination.
- Engineering, UX, QA and delivery
- Mobile/backend services, interface design, connectivity checks and delivery preparation.
- US banking and payroll providers
- Account services, direct-deposit switching, financial controls and provider status.
- FX and treasury counterparties
- Quotes, dollar settlement, peso prefunding and reconciliation responsibilities.
- Local card processors
- Card processing, web services, reports, disputes, country training and release acceptance.
- Compliance and fraud reviewers
- Policy review, identity/AML responsibilities, risk alerts and operating escalation.
Technology and integrations
Services in the workflow.
- US banking-as-a-service providerBanking-services provider
Banking-services counterparty; account and transaction interface.
2020–2022 · Banking interface
- PinwheelPayroll/direct-deposit service
Payroll API and direct-deposit switch capability.
2021–2022 · Payroll integration
- SardineFraud and screening service
Fraud, device and behavior service; sanctions, PEP and adverse-media screening.
2022 · Fraud and screening
- TwilioMessaging/verification service
SMS and one-time-password verification.
2020–2022 · Verification
- MastercardPayment network / program alliance
Payment-network role and El Salvador program alliance.
2021–2022 · Payment network
The design principle
Trace the customer instruction, the financial movement and the responsible institution separately, then reconcile them.