A Modern API for Financial Truth.
SignalCredit API is an open-source, consent-driven credit computation platform designed to provide transparent, explainable, and on-demand credit reporting and financial evaluation.
Rather than relying on a permanently maintained consumer credit file, SignalCredit API is designed around authorized computation. An individual authorizes a specific credit request, the system retrieves permitted financial information, evaluates that information using transparent and versioned models, generates an explainable report, and records the appropriate audit information.
The platform is designed to support authorized access by U.S.-registered businesses while maintaining consumer control over data access and report generation.
SignalCredit API is built as a modular system. Core modules provide the fundamental credit computation, authorization, security, reporting, transparency, and audit capabilities. Optional plugin modules extend the platform with additional data sources, scoring models, identity systems, financial services, and deployment capabilities without requiring changes to the core architecture.
SignalCredit API is designed to establish a modern credit infrastructure based on:
- Consumer authorization
- Open-source technology
- Transparent scoring methodologies
- Explainable artificial intelligence
- Minimal data retention
- Verifiable computation
- Strong security controls
- Fairness and bias evaluation
- Reproducible scoring
- Modular extensibility
The objective is to make credit computation understandable, auditable, and controlled by the individual whose financial information is being evaluated.
No credit report or financial evaluation should be generated without appropriate authorization from the individual.
Authorization should be:
- Explicit
- Cryptographically verifiable
- Time limited
- Scope limited
- Revocable where applicable
- Traceable through the audit system
SignalCredit API is designed to minimize persistent storage of sensitive financial information.
The preferred processing model is:
- Establish authorization.
- Retrieve permitted information.
- Validate the information.
- Normalize the information.
- Compute the requested evaluation.
- Generate explanations and supporting records.
- Deliver the authorized report.
- Retain only information required for security, auditing, legal compliance, and system operation.
Scoring logic should be publicly inspectable.
A credit result should provide enough information for an authorized party to understand:
- Which factors were evaluated
- Which factors affected the result
- The mathematical contribution of each factor
- Which model version was used
- Which data sources contributed information
- When the evaluation occurred
- Which rules and thresholds were applied
SignalCredit API should prioritize interpretable models and explanations rather than relying exclusively on opaque machine learning systems.
Core functionality remains independent from external providers.
External data sources, authentication providers, scoring models, storage systems, and other integrations can be implemented as plugins.
The project is developed as open-source software under the GNU Affero General Public License v3.0 or later (AGPL-3.0+).
SignalCredit API is organized into two primary architectural layers:
Core modules provide the fundamental functionality required to operate SignalCredit API.
Plugin modules provide additional capabilities that can be installed independently without making them mandatory dependencies of the core platform.
Conceptually:
Consumer → Consent → API Gateway → Data Layer → Computation → Explanation → Report
With supporting services:
Identity + Security + Audit + Model Registry + Governance
The API Gateway is the primary interface between SignalCredit API and authorized applications.
- API request handling
- API versioning
- Request validation
- Authentication integration
- Authorization enforcement
- Rate limiting
- Request signing
- Response formatting
- OpenAPI documentation
- API error handling
- Webhook event delivery
- REST API
- Versioned endpoints
- JSON-based request and response formats
- OpenAPI compatibility
- Secure API authentication
- Request correlation identifiers
- Rate limiting
- Idempotent operations
- Business integration support
The Consent & Authorization Module controls consumer permission.
- Create authorization requests
- Issue consent grants
- Validate authorization
- Enforce authorization scope
- Enforce expiration
- Support revocation
- Record consent events
- Cryptographic consent tokens
- Time-limited permissions
- Scope-limited access
- Consumer authorization records
- Consent status verification
- Authorization expiration
- Revocation support
- Business identity verification
A credit request must not bypass this module.
The Identity & Access Module provides secure authentication and access control.
- OAuth 2.0
- OpenID Connect
- WebAuthn and passkey support
- Role-based access control
- Attribute-based authorization support
- Multi-factor authentication support
- Session management
- Token validation
- Credential lifecycle management
The module separates consumer identity, business identity, application identity, and system identity.
The Consumer Control Module provides the individual with visibility into their SignalCredit activity.
- Authorization management
- Active permission display
- Permission revocation
- Credit report history
- Report access history
- Business request visibility
- Data source visibility
- Model version visibility
- Audit event visibility
The consumer should be able to understand who requested information, what was requested, why it was requested, and what was produced.
The Financial Data Ingestion Module provides a standardized interface for retrieving authorized financial information.
- Connector abstraction
- Data-source authentication
- Secure data retrieval
- Data validation
- Data normalization
- Source provenance
- Duplicate detection
- Data freshness tracking
- Temporary processing storage
The core module does not require a specific financial data provider.
External providers should be implemented through plugins.
Financial information can arrive in different formats and structures.
This module converts authorized source information into standardized internal representations.
- Account normalization
- Transaction normalization
- Income normalization
- Liability normalization
- Payment history normalization
- Credit account normalization
- Date and currency normalization
- Data quality validation
- Missing-data detection
- Source confidence metadata
Normalized information is passed to the scoring engine without coupling the scoring system to a specific provider.
The Credit Computation Module is the primary scoring engine.
- Deterministic scoring
- Versioned scoring models
- Configurable scoring factors
- Factor weighting
- Rule evaluation
- Threshold evaluation
- Risk classification
- Score generation
- Confidence metadata
- Reproducible calculations
Every computation should identify the exact model and configuration used.
The Explainable AI Module provides transparent explanations for model outputs.
- Factor-level explanations
- Feature contribution analysis
- SHAP integration
- Local explanation support
- Global model explanations
- Model feature documentation
- Explanation reproducibility
- Human-readable explanations
Recommended model approaches include:
- Explainable Boosting Machines
- Generalized Additive Models
- Logistic regression
- Decision trees
- Other interpretable tabular models
Black-box models should not be required for the core system.
The Fairness & Bias Module evaluates scoring models for potential disparate outcomes.
- Fairness metrics
- Bias detection
- Model comparison
- Population analysis
- Threshold analysis
- Fairness reports
- Model validation
- Pre-deployment testing
- Regression testing after model updates
Recommended open-source tooling includes:
- Fairlearn
- AI Fairness 360
- scikit-learn evaluation tooling
Sensitive demographic information should be handled according to applicable law and should not automatically become a scoring factor simply because it is available for auditing.
The Credit Report Module converts computation results into a standardized report.
- Consumer credit report generation
- Score presentation
- Factor breakdown
- Account information
- Payment history information
- Financial obligations
- Data source disclosure
- Model disclosure
- Calculation explanation
- Report timestamps
- Report identifiers
- Report integrity verification
Reports should clearly distinguish between:
- Raw source information
- Derived information
- Model-generated calculations
- Risk classifications
- Explanations
The Audit & Transparency Module creates a verifiable history of system activity.
- Append-only audit records
- Request logging
- Consent event logging
- Data access logging
- Model version logging
- Report generation logging
- Administrative event logging
- Cryptographic integrity verification
- Audit export
- Verification receipts
The audit system should make unauthorized activity detectable.
The Model Registry maintains the models used by SignalCredit API.
- Model versioning
- Model metadata
- Model hashes
- Training metadata
- Evaluation results
- Fairness results
- Approval status
- Deployment status
- Rollback support
- Reproducibility information
Each generated report should identify the model version used for its computation.
The Security Module provides security controls across the platform.
- TLS encryption
- Encryption at rest where persistent storage is required
- Key management
- Secrets management
- Zero-trust service communication
- Request signing
- Token validation
- Access control
- Rate limiting
- Security event logging
- Secure deletion mechanisms
- Threat detection integration
Security should be implemented as a system-wide requirement rather than an optional feature.
The Data Privacy Module controls sensitive financial information.
- Data minimization
- Ephemeral processing
- Retention policies
- Secure deletion
- Purpose limitation
- Access controls
- Data provenance
- Privacy event logging
- Consumer data access controls
The architecture should avoid unnecessary duplication of financial information.
The Developer Module provides tools for businesses integrating SignalCredit API.
- OpenAPI specification
- API documentation
- Authentication documentation
- Integration guides
- Sandbox support
- Example requests
- Example responses
- SDK architecture
- Webhook documentation
- Error documentation
Initial SDK targets may include:
- Python
- JavaScript / TypeScript
- Go
Plugin modules extend SignalCredit API without changing the core architecture.
Provides integration with financial institutions and account aggregation services.
Potential capabilities:
- Bank account retrieval
- Transaction retrieval
- Account verification
- Balance verification
- Financial history retrieval
Provides authorized income and employment data integrations.
Potential capabilities:
- Income verification
- Payroll history
- Employment verification
- Income consistency analysis
- Income frequency analysis
Provides additional authorized lending information.
Potential capabilities:
- Loan accounts
- Payment history
- Outstanding balances
- Loan terms
- Delinquency information
Provides authorized utility payment information.
Potential capabilities:
- Utility payment history
- Recurring payment analysis
- Payment consistency
- Account tenure
Provides optional authorized alternative financial information.
Potential capabilities:
- Rental payment history
- Insurance payment history
- Subscription payment history
- Other legally permissible financial indicators
Alternative data must remain subject to applicable consumer protection, privacy, and fair lending requirements.
Provides optional integration with existing credit reporting infrastructure where legally permitted.
Potential capabilities:
- Import existing credit information
- Compare source records
- Detect discrepancies
- Identify conflicting records
- Produce data provenance information
This plugin is optional and does not make external credit bureaus a required dependency of SignalCredit API.
Provides additional machine learning capabilities beyond the core interpretable scoring engine.
Potential technologies include:
- Gradient boosting
- Random forests
- Neural networks
- Transformer-based models
- Ensemble models
Any advanced model used for consequential credit evaluation should remain subject to the project's explainability, fairness, validation, auditability, and regulatory requirements.
Provides a natural-language interface for explaining credit reports.
Potential capabilities:
- Consumer-friendly report explanations
- Financial terminology explanations
- Factor explanations
- Report navigation
- Model documentation assistance
- Credit education
The AI assistant must not alter the underlying score or fabricate financial information.
Recommended open-source model families for this plugin may include:
- Llama
- Qwen
- Mistral
- Gemma
The selected model should be evaluated independently for accuracy, privacy, security, and hallucination risk.
Provides optional identity verification capabilities.
Potential capabilities:
- Document verification
- Identity matching
- Fraud detection
- Business verification
- Account ownership verification
Identity verification providers should remain replaceable through the plugin architecture.
Provides optional fraud and anomaly detection.
Potential capabilities:
- Suspicious application detection
- Transaction anomaly detection
- Identity anomaly detection
- Account takeover indicators
- Synthetic identity indicators
Fraud detection results should remain separate from the underlying credit score unless explicitly defined by a validated scoring specification.
Provides optional geographic financial context.
Potential capabilities:
- Regional economic indicators
- Local housing information
- Regional employment information
- Cost-of-living indicators
Geographic information must be evaluated carefully to avoid prohibited discriminatory effects.
Provides jurisdiction-specific compliance capabilities.
Potential capabilities:
- Regulatory reporting
- Compliance checks
- Retention controls
- Consumer dispute workflows
- Adverse-action documentation
- Regulatory audit exports
The plugin architecture should allow requirements to evolve without rewriting the core computation engine.
Provides consumer mechanisms for challenging inaccurate information.
- Dispute submission
- Evidence submission
- Data-source notification
- Investigation workflow
- Correction tracking
- Resolution notices
- Dispute audit trail
Provides optional communication capabilities.
Potential integrations may include:
- SMS
- Push notifications
- Webhooks
- Secure application notifications
Notifications should never expose sensitive financial information unnecessarily.
- Python
- FastAPI
- Pydantic
- PostgreSQL where persistent storage is required
- Apache Arrow for in-memory data processing
- scikit-learn
- InterpretML
- Explainable Boosting Machines
- SHAP
- Fairlearn
- AI Fairness 360
Optional open-source language models:
- Llama
- Qwen
- Mistral
- Gemma
Language models should primarily support explanation and assistance rather than independently determine creditworthiness.
- OAuth 2.0
- OpenID Connect
- WebAuthn
- Passkeys
- TLS 1.3
- Modern cryptographic libraries
- Hardware-backed key storage where available
- Secrets management
- Zero-trust service authentication
- Signed authorization tokens
- Docker
- Kubernetes
- Linux
- Infrastructure-as-code
- CI/CD
- Automated security testing
- Append-only event storage
- Cryptographic hashes
- Merkle-tree verification where appropriate
- Tamper-evident audit records
A standard SignalCredit request follows this sequence:
- A consumer begins a credit application.
- The business creates a credit evaluation request.
- The consumer authenticates with SignalCredit.
- The consumer reviews the requested permissions.
- The consumer authorizes the request.
- SignalCredit validates the consent grant.
- Authorized data connectors retrieve permitted information.
- The data normalization module validates and standardizes the information.
- The credit computation module evaluates the information.
- The explainability module calculates factor contributions.
- The fairness and validation systems verify the applicable model state.
- The report module generates the credit report.
- The audit module records the appropriate verification information.
- The authorized business receives the report.
- Temporary processing information is securely removed according to the applicable retention policy.
Every credit evaluation should be capable of identifying:
- Consumer authorization
- Requesting business
- Request identifier
- Data sources used
- Data timestamp
- Scoring model
- Model version
- Model configuration
- Factors evaluated
- Factor contributions
- Final result
- Explanation
- Audit information
A result should never simply state:
Score: 642
It should provide the supporting information necessary to understand how that result was produced.
SignalCredit API is designed around a zero-trust security model.
Security requirements include:
- Authenticate every service
- Authorize every protected operation
- Encrypt sensitive data in transit
- Encrypt required persistent data at rest
- Minimize sensitive data retention
- Separate consumer and business identities
- Rotate credentials and keys
- Record security events
- Detect anomalous access
- Apply least-privilege permissions
- Securely delete temporary financial information
- Regularly test the complete system
No architecture can honestly guarantee that a system will experience "no leaks." SignalCredit API should instead be engineered so that a breach is difficult to execute, limited in scope, detectable, and recoverable.
SignalCredit API is intended as technical infrastructure and does not by itself establish compliance with U.S. financial, consumer protection, credit reporting, privacy, or fair lending laws.
A production deployment must be evaluated against applicable requirements, which may include:
- Fair Credit Reporting Act
- Equal Credit Opportunity Act
- Fair Housing Act where applicable
- Gramm-Leach-Bliley Act
- Applicable state privacy laws
- Applicable state consumer protection laws
- Applicable financial institution requirements
The system should support regulatory compliance through explicit architecture, documentation, auditability, consumer rights workflows, and configurable compliance controls.
SignalCredit API is designed to remain fully open-source.
The project should maintain:
- Public source code
- Public API specifications
- Public model definitions
- Public model version history
- Public documentation
- Reproducible builds
- Transparent issue tracking
- Community review
- Security disclosure processes
- Documented governance procedures
The project should maintain automated testing across:
- Unit tests
- Integration tests
- API tests
- Security tests
- Authentication tests
- Authorization tests
- Model validation
- Fairness testing
- Data validation
- Privacy testing
- Performance testing
- Regression testing
- Reproducibility testing
Every scoring model should be evaluated before deployment and after material changes.
Contributions are welcome.
Developers and researchers can contribute to:
- Core platform modules
- Scoring models
- Explainability
- Fairness analysis
- Security
- Privacy
- Data connectors
- Plugins
- Documentation
- Testing
- Developer tooling
All contributions must comply with the project's AGPL-3.0+ licensing and attribution requirements.
SignalCredit API is intended to provide a foundation for a new generation of credit infrastructure where financial evaluation is:
Authorized. Transparent. Explainable. Auditable. Open Source.
The long-term vision is a credit computation network that gives individuals meaningful control over their financial information while providing authorized businesses with reliable, verifiable, and transparent credit intelligence.
A Modern API for Financial Truth.
- Fully AGPL-3.0+ compliant system
- Copyleft enforced for network deployments
- Required attribution:
- Roxanne Ardary
- https://www.roxanneardary.com/
- Specification Branding License (SBL)
- Attribution-free commercial deployment
- Pricing based on scale, usage, and deployment scope
- https://roxanneardary.com/signalcreditapi/
SignalCredit API is released under the GNU Affero General Public License v3.0 or later (AGPL-3.0+).
By contributing to this project, you agree that your contributions will also be released under this license.
Please note the following:
- All contributions must comply with the AGPL-3.0+ terms.
- Under Section 7 of the license, all redistributions, forks, and derivative works must preserve attribution to:
Roxanne Ardary and roxanneardary.com. - SignalCredit API specificiations are free to use with attribution. A Specification Branding License can be negotiated upon request.
- The project's notice.md file tracks attribution requirements and contributor acknowledgments.
Any update that adds new contributors or modifies attribution should also updatenotice.md. - When submitting a pull request, ensure that any new files maintain the attribution headers where applicable.
- Network-deployed versions of this software must also remain fully AGPL-3.0+ compliant, including exposure of source code modifications when applicable under the license.
For full legal details, please refer to the AGPL-3.0+ license and the project's notice.md file.