A bounded, reviewable process
How it works
FL-BSA (Fair-Lending Bias-Simulation Appliance) connects a simulation question to the assumptions and evidence needed to review its result.
Agree the scenario
Define the credit workflow, population, evidence question and approved synthetic input boundary before running a test.
Run the simulation
Compare decision patterns across synthetic borrower groups inside your environment. Record the configuration and assumptions with the outputs.
Review the evidence
Inspect the report, metrics and manifest. Verify bundle consistency, record limitations and agree the next action with the responsible team.
Choose the starting point
Engagement options
Start with evidence readiness when the question is still taking shape. Scope an optional evaluation when the workflow and customer-controlled environment are ready.
Evidence-readiness assessment
About 5 business days
For a fast proceed, pause or stop recommendation. A short findings memo covers the workflow, schema, data boundary and evidence gaps.
Recommended starting point.
Evidence readiness sprint
About 2 weeks
For teams preparing a controlled run. An evidence-gap memo, draft acceptance checklist and scoped plan establish what the run needs to demonstrate.
Fair outcomes evidence sprint
6 to 10 weeks
One controlled, customer-hosted FL-BSA simulation, with traceable outputs, an explicit limitations record and a governance readout.
Pricing is provided on request. Terms and delivery are agreed for the available release; any pre-release handoff requires separate approval.
Optional pre-release evaluation
Evaluate one workflow
Explore synthetic credit-decision patterns for one regulated-credit workflow in your own environment. Inspect sample evidence before discussing an evaluation.
For an organisation with a time-bound need, agree one question, the approved input boundary and proceed, pause or stop criteria. The typical 6 to 10 week engagement includes a runbook, one supported simulation and a governance readout.
Full public stable release is the product destination and is not yet published. This optional engagement is not the release programme or a release gate.
Run inside your environment
The intended AWS route is AMI-first. Supported container/VM paths may be agreed separately. Public AWS Marketplace access is not yet available.
Data boundary: In the configured self-hosted deployment, borrower datasets, model parameters and protected-attribute data stay within the customer environment.
Confirm the version, terms and delivery approval before installation. See Procurement & Deployment for the sequence and runtime prerequisites.
Creditworthiness evidence readiness
Scope one workflow, map the available evidence and identify the missing measures, owners and action criteria before selecting a test.
The revised EU Consumer Credit Directive rules are due to apply from 20 November 2026. Article 18 requires documented and maintained creditworthiness-assessment procedures; where an assessment involves automated processing of personal data, it also provides consumer-request rights to human intervention, an explanation, and review. Read Article 18.
Equilens supports evidence-readiness review and controlled-evaluation planning. It does not provide legal advice, certify compliance, validate a model, or make live lending decisions.
Governance context
Evidence mappings support review against FCA Consumer Duty, the EU AI Act and US ECOA touchpoints. They do not replace legal, compliance or model-risk judgment.
EU AI Act timing and the synthetic-data question
The high-risk rules for relevant creditworthiness and credit-score systems are due to apply from 2 December 2027.
EU AI Act Article 4a includes whether bias detection and correction can be achieved effectively with other data, including synthetic or anonymised data, among the conditions for its exceptional special-category-data route. An evaluation records what the simulation establishes and what it does not.
For security posture, signature scope and independent verification, visit the Trust Center.
Documentation
Public samples show the evidence format and verification process. They use synthetic data and are labelled DEMO/EVALUATION; they are not customer output or a regulatory certification.
Technical whitepaper
The full regulated-credit evidence model, robustness characterization, limitations, and offline verification. PDF, 21 pages, 934 KiB.
Download technical whitepaper (PDF)Download verification companion (ZIP, 101 KiB)Sample report
Report from the balanced public demo scenario. PDF, 17 pages, 234 KiB.
Download demo report (PDF)Five checks before a test
Decision scope, evidence question, data boundaries, named owners and action criteria.
Read the noteRequest the buyer pack to confirm the technical documentation and delivery route available for your engagement.
Common questions
Does FL-BSA test our actual production model?
No. The current product simulates decision patterns over synthetic borrower cohorts. It does not load or execute your models or scorecards. Measurement over customer-authored decision or score columns is a separate development track and is not part of the current release.
What is included in the evidence bundle?
A PDF report, metrics, an evidence manifest recording the dataset hash, random seed and software version, and certificate appendices. These are technical evidence artifacts, not regulatory certifications.
Does any customer data leave our environment?
In the configured self-hosted deployment, compute stays in your VPC or VM. Borrower datasets, model parameters and protected-attribute data are not sent to Equilens-controlled services. Any optional usage metering is configured separately.
How can FL-BSA be deployed?
The intended AWS path is AMI-first. Supported container or VM paths may be agreed separately. Public AWS Marketplace access is not yet available. The selected native v5 runtime is CPU-based; GPU acceleration is not part of that runtime.
How long does a typical run take?
There is no published validated exact-version native sizing baseline or customer SLA. Measure the delivered artifact on the target hardware. Runtime depends on input shape, hardware, configuration and enabled validation work.
Can we verify the evidence ourselves?
Yes. Bundles are hash-linked using SHA-256 and include a hashing specification. Where signatures are enabled, vendor-authored attestations can be verified against the published vendor trust root. Customer-local bundle consistency does not by itself prove vendor authorship. Verification can be performed offline.