Designing a Risk-Aware POS System for In-Store Lending
Optimizing compliance, reducing financial harm, and improving operational clarity under regulatory pressure.
Business Context
The Retail POS system supports in-store lending applications for installment and payday loans at Money Mart, a large retail financial services provider. Financial Service Representatives (FSRs) process applications on behalf of customers in a co-present retail environment.
Key realities:
Average application time: ~20 minutes
~10 applications per store per day (avg)
Hard credit check triggered at final submission
Government tightened approval regulations, increasing rejection risk
Income verification largely manual
Tablet-based document signing required per-application authentication
This created operational inefficiencies and exposed customers to unnecessary hard credit inquiries.
The challenge was not speed alone.
It was reducing regulatory risk, minimizing financial harm to customers, and improving reliability within retail constraints.
Primary Users & Environment
Financial Service Representatives (FSRs)
1–20 years tenure range
Moderate technical proficiency
Serve both tech-savvy and elderly customers
Operate in interruption-heavy retail environments
Process ~10 applications daily
The experience had to support:
Speed under pressure
Accuracy under compliance scrutiny
Clarity for mixed digital literacy customers
Co-present device interaction (POS + tablet)
Core Operational Problems
3.1 Hard Credit Pull Triggered Too Late
Before submission:
FSR verifies contact information
Verifies driver’s license
Edits income details
Uploads or scans proof of income
Completes full form
Only at final submission does the hard credit hit occur.
If rejected:
Customer credit score impacted
20 minutes of effort wasted
Emotional friction at the counter
Store rejection metrics increased under tightened regulations
This exposed customers to avoidable financial harm.
3.2 Manual Income Handling
Before automation:
Income entered manually
Physical documents scanned
Customers sometimes emailed proof to backend office
Reconciliation handled manually
High risk of entry errors
The process was slow, error-prone, and operationally heavy.
3.3 Repeated Signing Authentication
Tablet-based document signing required:
6-digit code per application
Re-entry for each new session
Observed in-store behavior:
Customers struggled entering codes
Elderly customers required assistance
Repeated interruptions during signing
This created unnecessary cognitive load in a high-pressure environment.
Solution 1: Quick Apply (Soft Eligibility Gate)
Objective
Introduce a pre-eligibility estimation before triggering a hard credit inquiry.
How It Works
Quick Apply:
Uses provided income and profile data
Does not trigger hard bureau check
Provides eligibility estimation
If customer fails Quick Apply:
FSR does not proceed to full application
Hard credit hit avoided
Customer credit health protected
Quick Apply Results Screen
Strategic Impact
Quick Apply did not reduce the 20-minute application duration.
It reduced:
Unnecessary hard credit pulls
Rejections after regulatory tightening
Emotional friction at point-of-sale
Operational waste for FSRs
This reframed the flow from “submission-first” to “risk-aware progression.”
4.1 Iteration Based on Field Testing (Income Inputs)
At MVP
After User Testing
After User Testing
At MVP launch, Quick Apply supported only a single income field.
Through usability testing with FSRs, we observed a recurring issue: many customers rely on multiple income sources (e.g., part-time wages, secondary employment, government benefits). Limiting the form to one income produced inaccurate eligibility estimations and reduced approval precision.
Based on this feedback, we iterated the Quick Apply form to:
Support multiple income entries
Introduce a frequency dropdown for each income source
Allow clearer representation of real-world earning patterns
This significantly improved eligibility accuracy without increasing complexity for FSRs.
The iteration demonstrated the importance of aligning underwriting estimation models with the financial realities of customers rather than simplifying purely for MVP speed.
Solution 2: Persistent Tablet Connection (SignalR)
Before
6-digit code required per application
Frequent errors and delays
After
Persistent POS-tablet connection
Auto-push of documents
No repeated authentication per application
Manual disconnect only via system reset
Impact
Reduced in-store friction
Lower cognitive load for customers
Smoother co-present signing experience
Fewer interruptions during application flow
This removed redundant authentication loops in a retail lending environment.
Solution 3: Income Automation via Flinks
Before
Manual income entry
Physical scanning of proof
Email-based documentation handling
Backend manual validation
After
Direct income fetching via integration
Reduced manual entry
Standardized financial data ingestion
Lower dependency on document scanning
Impact
Reduced operational overhead
Improved data consistency
Lower human error risk
Improved compliance confidence
This transitioned income verification from human-dependent validation to structured financial data integration.
Default
Options for Flinks
Pop-up for SMS option
Pop-up for QR option
FSR Flinks screen for SMS
FSR Flinks screen for QR option
Customer Flinks screen for QR (on Tablet)
Successful fetch of income pop-up
Successful fetched Income screen
6.1 Product-Specific Primary Income Control
Beyond automation, we enhanced how primary income is selected across products.
Successful fetched Income screen
Previously, income sources were rigidly structured, limiting FSR flexibility when handling short-term lending products. We introduced the ability to modify the primary income source specifically for SPL (Short-Term Lending), while maintaining locked logic for Installment Loans and Credit Cards.
We also added clear product-specific tags to indicate which income source was being used for IL and Credit Card underwriting, ensuring transparency and preventing accidental misalignment.
Impact
~8–12% improvement in SPL approval conversion after enabling primary income flexibility
~10–15% increase in average approved amount for eligible SPL customers due to more accurate income aggregation
100% preservation of underwriting rule integrity across IL and Credit Card (no policy changes required)
~20% reduction in FSR clarification steps when handling multi-product applications (based on pilot store observations)
This was not a UI change—it was underwriting logic surfaced through clearer experience design.
Multi-Product Decision Summary (Post Quick Apply)
Before
FSRs initiated one product at a time (e.g., Installment Loan or Payday Loan).
Hard credit check returned eligibility only for the selected product
Approved amount shown within that single-product flow
No visibility into other potentially approved products
This limited cross-sell visibility and required restarting flows to explore other products.
After Quick Apply + Product Integration
We introduced an Application Decision Summary screen immediately after eligibility determination.
This screen:
Displays all approved products simultaneously
Shows approved amounts and key financial terms
Allows FSR to proceed with one product at a time
Prevents redundant credit checks
Approved products may include:
Installment Loan
Payday Boost
Credit Card
Products Approved After Hard Hit
Strategic Impact
This change shifted the system from product-first to eligibility-first architecture.
It:
Increased transparency for FSRs
Reduced need to restart flows
Improved cross-sell opportunity visibility
Structured multi-product decision-making within a single bureau pul
The decision summary centralized risk output and separated underwriting from product completion.
7.1 Returning Customer Eligibility Visibility (Dashboard Tiles)
To support real-world store behavior, we extended eligibility visibility beyond the immediate session.
We designed new dashboard tiles that surface Quick Apply results and approved product outcomes for up to 7 days after the initial check.
If a customer returns within that window:
FSRs can immediately see previously approved products
Eligibility context is preserved without re-running the full application
Conversations can resume without triggering another bureau pull
This reduced redundant checks, protected customers from unnecessary credit activity, and enabled more informed, confident discussions at the counter.
It also reinforced the shift from transactional applications to eligibility-aware customer records.
Dashboard if customer left at quick apply
Credit Card Expansion (In Development)
At the time of hard credit check:
Installment loan eligibility assessed
Credit card eligibility assessed simultaneously (Brim partnership)
This expands product surface area without requiring additional credit pulls.
Strategically, this increases revenue opportunity while preserving underwriting efficiency.
Regulatory & System Constraints
This system operated under:
Tightened government approval requirements
Credit bureau integration limitations
Legacy POS architecture
Co-present dual-device interaction
Mixed digital literacy customer base
The design challenge was balancing:
Compliance strictness
Customer protection
Operational speed
Store-level rejection metrics
9.1 AML Standardization (Large Cash Transaction Reporting – LCTR)
We also designed a standardized Large Cash Transaction Report (LCTR) workflow for transactions exceeding $10,000 within a 24-hour period, aligning with AML and FINTRAC requirements.
Previously, reporting relied on fragmented processes within Core POS, leading to inconsistent data capture and additional manual reconciliation.
The new LCTR screen:
Standardized required AML fields
Improved clarity of mandatory reporting inputs
Reduced manual steps when generating regulatory reports
Prepared Evolve to become the unified compliance workflow across products
This strengthened regulatory reliability while reducing operational burden on store staff.
Large Cash Transaction Report if the Customer themselves making the payment
Embedded User Testing with FSR Cohort
To ensure solutions aligned with real store workflows, we established a small group of selected FSRs who regularly participated in usability validation.
For major features (Quick Apply, multi-product summary, income enhancements, dashboard tiles), I created interactive prototypes and conducted structured walkthrough sessions.
In many cases, I tested two alternative solutions and asked FSRs to:
Complete realistic task scenarios
Verbalize expectations and confusion points
Compare both approaches and explain which felt more natural
This approach allowed us to:
Validate workflow assumptions before development
Detect friction early in prototype stage
Align system logic with how FSRs actually think at the counter
Reduce retraining needs at rollout
Several iterations — including multi-income support and dashboard eligibility visibility — directly resulted from these sessions.
This embedded testing loop ensured the system evolved with operational reality rather than abstract design assumptions.
Observed & Operational Impact
Quantitative
Average application time remained ~20 minutes
Reduced unnecessary hard credit hits (directional impact)
Lower rejection exposure under stricter regulations
Qualitative
Reduced customer frustration during signing
Lower FSR cognitive load
Fewer wasted full applications
Improved perceived professionalism of process
Systems-Level Thinking
This project required designing across:
Compliance rules
Credit bureau mechanics
Retail operations
Human behavior under financial stress
Dual-device synchronization
12.1 Designing for Business Insight vs. Customer Comfort (Purpose of Loan)
We introduced a "Purpose of Loan" step to capture customer intent and inform product strategy.
While the data provided useful business insights, field observations revealed that customers perceived the question as intrusive. Over time, FSRs informally bypassed or rushed this step, reducing data reliability.
The feature was ultimately deprecated.
This decision reinforced an important principle: in high-trust financial interactions, perceived judgment or intrusion can outweigh analytical value.
The focus was not visual redesign.
It was:
Financial harm prevention
Risk buffering
Operational resilience
Expectation management under regulation
Key Takeaway
In regulated fintech environments, UX is not about making flows shorter.
It is about reducing irreversible harm, protecting customer credit health, and absorbing regulatory volatility through experience architecture.
Quick Apply protected customers.
Persistent signing reduced friction.
Income automation reduced human error.
Together, they shifted the POS from form-processing software to a risk-aware retail lending system.
Designing high-trust products that balance compliance, clarity and conversion.
Schedule a call with Abhijeet
