Sherlocked.ai
Federated learning for inclusive lending
Business Problem
Banks and financial institutions want to extend credit to underbanked segments but are structurally limited: the customer data needed to build accurate risk models for these segments is sensitive, regulated, and fragmented across institutions that have no incentive, or legal ability, to pool it into a shared dataset.
Customer / User Context
The target customer is a financial institution's lending or digital assets team, not a consumer. Early discovery conversations focused on what would actually make an institution trust a third-party model with lending-adjacent decisions: data never leaving their environment, explainability, and a clear regulatory story, more than raw model accuracy.
Approach
Sherlocked.ai's product thesis is that federated learning lets multiple institutions collaboratively improve a shared model without centralising customer data, addressing the privacy and compliance objection that kills most cross-institution AI proposals at the first conversation. The venture is at the validation stage, building on product strategy, customer discovery interviews with financial institutions, and structured mentor feedback.
Architecture
The target architecture keeps each institution's data and compute local while still enabling collaborative model improvement. Each institution trains within its own AWS environment (Amazon SageMaker for training, S3 for encrypted local data storage), and only model weight updates, never raw customer data, are sent to a central aggregation service on AWS (ECS and Lambda) that combines updates into a shared model via federated averaging. The updated global model is redistributed back to each institution through a versioned API layer on API Gateway, so no institution has to expose its underlying customer data to a third party or to other institutions.
01
Business Workflow
Institution lending review, underserved-segment risk assessment
02
Data Sources
Customer and transaction data held locally within each institution's AWS environment
03
System Architecture
Federated training on Amazon SageMaker, aggregation via ECS and Lambda, distribution through API Gateway
04
Deployment Architecture
Containerised per institution on AWS Fargate, IAM-scoped access, encrypted model-update transport
05
Business Outcome
Expanded addressable lending market for partner institutions without centralising data
Technology Stack
Business Outcome
As an early-stage venture, the outcome to date is validated product direction, not deployed business metrics: structured discovery conversations with financial institutions and mentors have sharpened the thesis toward institutional trust and compliance requirements ahead of a pilot.
Lessons Learned
The biggest product lesson so far is that “privacy-preserving AI” is a feature pitch, not a business case, until it's translated into the specific compliance and risk-committee language a financial institution's stakeholders actually use to approve a vendor. Customer discovery in regulated industries has to include the compliance and risk stakeholders from the first round of conversations, not after a pilot is already proposed.
Deployment
The deployment architecture is containerised and cloud-native on AWS: each institution's training environment runs in an isolated container with IAM-scoped access, model updates move through an encrypted API layer, and the aggregation service scales independently on Fargate. Onboarding a new institution is a configuration change against this architecture rather than a platform rebuild.