How MULA-X built a financial platform for workers without traditional credit files
Workers without conventional banking records or credit histories needed financial products that could handle identity, consent, balances, employer benefits and transactions without assuming a typical credit-file journey.
Devntech’s scope: Devntech delivered backend platform, identity, consent, API, administration and modernization work. MULA-X’s regulated products, scoring approach and provider relationships are client context and are not represented as Devntech-created outcomes.
Hero visual
Financial products operating on one controlled platform
A product overview using demonstration identities and redacted financial values.
The engagement
What Devntech built for MULA-X
MULA-X developed financial products for workers in Thailand, including lending, wallet, earned-wage access and employer-funded benefits. Devntech took over an incomplete platform and built backend, API and operational capabilities around financial-product workflows.
What we changed
- 1
Took over and expanded an incomplete financial-services platform.
- 2
Built backend capabilities for lending, wallet, earned-wage access and employer-benefit workflows.
- 3
Strengthened identity, consent, balance integrity, APIs and operational controls.
Qualitative evidence
What changed operationally
- Wallet, earned-wage access, lending and employer-benefit workflows operate on one configurable backend foundation.
- Identity, consent, product eligibility, balances and transaction state are connected instead of treated as separate product records.
- Administration, API and audit controls provide a defined operating surface for later product and partner integrations.
Evidence standard: These are delivered workflow and operating-state changes supported by the project record. They are qualitative results, not estimated percentages or modelled savings.
What Devntech continued to own
- Backend platform
- API integration
- Operational controls
This is what we mean by
Internal applicationsOperational flow
How the system works
The system is organized around three operational steps, with each handoff tied to a clear purpose and owner.
Workflow visual
Identity, consent, product access and transaction state
An annotated platform flow with regulated decisions and provider boundaries clearly identified.
Step 1
Establish identity and consent
Product access begins with user identity and consent flows appropriate to the platform.
Step 2
Operate financial-product state
Balances, eligibility and transaction state are handled as shared backend responsibilities.
Step 3
Support products through APIs and operations
Employer and product integrations can work from a controlled platform foundation.
What changed in practice
Capabilities built around the real workflow
Specific system capabilities, described by the operational job they do.
Product state
An explainable balance and transaction record
A redacted administration view showing product, balance and transaction status without customer data.
- Multi-product backend
- Supports several financial-product workflows without treating each as a separate platform.
- Identity and consent controls
- Builds operational safeguards into how users enter the product.
- Platform takeover and modernization
- Stabilizes and extends an inherited system with limited handover.
More like this
Internal software
Tastemedia
Food and culture publishing, Toronto
Integration · Automation · Managed system
CrystalCommerce
Specialty retail commerce platform
Got a workflow like MULA-X’s?
Describe the process. We come back with what it costs today, what could be automated and what we would build first.
- For businesses with $5M to $30M in revenue
- No long-term commitment
- Start with one workflow
- Keep ownership of everything we build