Utilized as the framework for building this banking API, enabling RESTful endpoints and comprehensive documentation via Swagger UI and ReDoc.
Serves as the programming language for the API implementation, with specific version requirements (3.8+) noted for compatibility.
Provides the database backend with indexed CustomerOID fields, supporting all portfolio and customer data storage with proper referential integrity.
Offers interactive API documentation through a UI available at /docs, allowing developers to explore and test all available endpoints.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Dummy Bank APIshow portfolio data for customer 550e8400-e29b-41d4-a716-446655440000"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Dummy Bank API Documentation
A comprehensive FastAPI-based banking API designed for portfolio analysis and customer data management, optimized for CustomerOID-based operations and MCP (Model Context Protocol) server integration.
๐ Quick Start
Prerequisites
Python 3.8+
Conda environment (recommended)
Installation & Setup
Set up environment:
conda create -n openbanking-backend python=3.11 conda activate openbanking-backendInstall dependencies:
pip install fastapi uvicorn sqlmodel sqlite3Start the API server:
conda run -n openbanking-backend uvicorn main:app --host 127.0.0.1 --port 3000 --reloadAccess API documentation:
Swagger UI: http://127.0.0.1:3000/docs
ReDoc: http://127.0.0.1:3000/redoc
Related MCP server: Finance Tools MCP
๐ API Overview
Base URL
Core Features
CustomerOID-centric design: All operations are based on unique Customer IDs (UUID format)
Comprehensive portfolio data: Assets, transactions, bank accounts, spending patterns, derivatives
Customer lifecycle management: Registration, deletion, and data retrieval
MCP server integration ready: Optimized responses for analysis agents
SQLite database: Local file-based storage with indexed CustomerOID fields
๐ CustomerOID Format
The API uses UUID format for CustomerOIDs:
Format:
550e8400-e29b-41d4-a716-446655440000Generation: Automatic UUID generation for new customers
Validation: Strict UUID format validation with backward compatibility
๐ Data Models
User
customer_oid(UUID): Unique customer identifiername(string): Customer name
Asset Holdings
Asset type, symbol, quantity, current value
Market data and performance metrics
Bank Accounts
Account details, balances, institution information
Multiple accounts per customer supported
Transactions
Transaction history with amounts, dates, descriptions
Categorized for analysis
Spending Patterns
Spending categories and amounts
Useful for financial behavior analysis
Derivative Transactions
Options, futures, and other derivative instruments
Advanced portfolio components
๐ API Endpoints
Customer Management
GET /customers
List all registered customers.
Response:
POST /register-customer
Register a new customer in the system.
Request Body:
Response:
Features:
Auto-generates UUID if
customer_oidnot providedValidates name (minimum 2 characters)
Prevents duplicate registrations
Returns comprehensive error messages
DELETE /customer/{customer_oid}
Delete a customer and all associated data.
โ ๏ธ WARNING: This permanently deletes all portfolio data for the customer.
Response:
GET /customer/{customer_oid}/exists
Quick check if a CustomerOID exists in the system.
Response:
Portfolio Data
GET /user-portfolio/{customer_oid}
Get comprehensive portfolio data for a customer.
Response Structure:
System Health
GET /health
Health check endpoint for monitoring.
Response:
๐ Database Schema
Tables
users: Customer information with UUID CustomerOID (indexed)
assets: Investment holdings per customer
bank_accounts: Banking account details
institutions: Bank and financial institution data
transactions: Transaction history
spending: Spending pattern data
derivative_transactions: Derivative instrument trades
Key Features
Indexed CustomerOID: All tables indexed on
customer_oidfor fast queriesReferential integrity: Proper foreign key relationships
SQLModel ORM: Type-safe database operations
Automatic seeding: Sample data for testing and development
๐งช Testing
Test Files Included
test_api.py: Comprehensive API testingtest_registration.py: User registration workflow testingreset_database.py: Database reset and reseeding
Running Tests
๐ง Configuration
Environment Variables
Port: Default 3000 (configurable)
Host: Default 127.0.0.1
Database: SQLite file
banking.db
Sample Data
The API includes comprehensive sample data for 5 customers:
Complete portfolio data
Multiple asset types
Various transaction patterns
Diverse spending categories
Derivative instruments
๐ฏ MCP Server Integration
This API is optimized for MCP (Model Context Protocol) server integration:
Key Features for MCP
CustomerOID-centric design: Easy customer identification
Comprehensive data structure: All portfolio data in single endpoint
Analysis-ready format: Pre-calculated summaries and metrics
Efficient queries: Indexed database operations
Standardized responses: Consistent JSON structure
Recommended MCP Usage
Customer Discovery: Use
/customersto list available customersPortfolio Analysis: Use
/user-portfolio/{customer_oid}for complete dataCustomer Management: Use registration/deletion endpoints for lifecycle management
Health Monitoring: Use
/healthfor system status
๐จ Error Handling
Common Error Codes
400: Invalid CustomerOID format or validation errors
404: Customer not found
409: Duplicate customer registration
500: Internal server errors
Error Response Format
๐ Development Workflow
Making Changes
Edit code: Modify
main.pyordb.pyRestart server: Server restart required for validation changes
Test changes: Run test scripts to verify functionality
Reset data: Use reset script if database schema changes
Adding New Customers
๐ Best Practices
CustomerOID Management
Always use UUID format for new customers
Validate CustomerOID before database operations
Use the provided validation function consistently
Database Operations
Use dependency injection for database sessions
Implement proper error handling and rollbacks
Close sessions properly to prevent leaks
API Design
Follow RESTful conventions
Provide comprehensive error messages
Include validation for all inputs
Document all endpoints clearly
๐ค Contributing
Follow the existing code structure
Add tests for new functionality
Update documentation for API changes
Ensure CustomerOID validation is maintained
Test with sample data before deployment
๐ License
This is a dummy/example implementation for development and testing purposes.
Need help? Check the Swagger documentation at http://127.0.0.1:3000/docs when the server is running.