Requirements

Functional:

Account Management:

• Allow administrator to create user account on site:
• require : user nric , dob , name, witness
• Allow registered user to
• login using user id and password
• view transations, account balance, credit card bill
• allow user to update address and password
• [implementation]:
  • with keycloak for user account management
  • with user account data in postgresql db

Fund transfers:

• Users should be able to transfer funds securely to other users or external accounts.
• The system should support different transfer methods such as bank transfers, credit/debit card transfers, and peer-to-peer transfers.
• Users should have the option to set up recurring transfers or schedule future transfers.
• Payment processing
• user should be able to make payments to merhants for good and services. the esystem should support various payment methods including credit/debit cars, bank tansfers and digital wallets.
• payment should be processed securely using encryption and tokenization to protect sentitive information
• [implementation]:
  • integrate with payment gateways(stripe api/paypal) and card networks to handle the complex compliance , security (PCI DSS), and communication between banks
  • Webpage will directly use stripe webapp to as they already have compliance like PCI.

Fraud detection

• implement algorithm to detect and prevent fraudulent transactions in treal time.
• analyze transation pattern,user behavior and other relavent data to identify suspicious activites.
• user should be notificied promptly if any potenitally fradulent activity is detected on their account
• [implementation]:
  • for user behavior deep learning model LSTM can be trained with historial data of suspicious pattern to detect suspicious activitity.

Buyer and Seller protection

• Provide mechanisms to resolve disputes between buyers and sellers, ensuring fair and secure transactions.
• Implement policies and procedures for handling chargebacks, refunds, and disputes in accordance with industry standards.
• [implementation]:
  • implementation with postgresql to track status , communication and evidence
  • user upload file to store in object stoage like minio with restructed access via identify provider like keycloak

Multi-current support

• have a multi current account to support transaction in mutiple currencies to accomodate international payment
• have system to have up to date exchange rate from currency conversion.
• [implementation]:
  • uses relational data like sql for acid compliance
  • cron job to get exchange rate from finanical data api like fixer.io or currency api to retrieve latest rate and stored in reddis cache (hashmap) to provide low latency access for conversion service.

Non-Functional:

scalability:

• able to handle growing user base and increase transaction volume.
• scaling horizontally (adding more machine ) based on demand.
• [implementation] :
  • implemented with kubenetes and scaling horizontally by monitoring average cpu usage based on default container runtime for service. 30% to scale in and 60% to scale up.
  • kubenetes services will implement load balancing using a round robin algorithm to evenly distribute load.

relability:

• have a uptime of 99.999%
• [implementation]:
  • multi az-deployment to achieve fault tolerance in case , data centre went down there are still at least two more handling the workload.
  • for database can use managed service to like amazon aurora postgreSQL which have 6 copies across 3 AZ. self manage postgresql can use bitnami postgresql-repmgr for automatic failover with health check built-in.
  • for service new pod will be spawn to handle workload .

useability:

• The user interface should be intuitive and easy to use, catering to users of all technical levels.
• Provide clear and concise instructions for performing various actions such as fund transfers and payments.
• Support multiple languages and accessibility features to ensure inclusivity.
• [implementation]:
  • use a frontend framework with built in i18n libraries
  • conduct user testing sessions to gather feedback on UI designs.
  • include an onboarding tutorial for new users to guide them through core functionalities.

monitoring and logging:

• implement logging for all system activites and transaction for audit and troubleshoot purpose.
• to track system performance , security incident
• design incident response framework to act on the logs collected.
• implement anomaly detection right within th e monioring tools to identify ongoing issues immediately.
• system log to be stored for 3 years and transational logs for 6 years (at least five years)
• [implementation]:
  • prometheus to pull require meteric from instance
  • grafana to visualise data
  • logging can be implementated with immudb with tamper proof and cryptographic verification.

Security:

• security in transit, security at rest, account security.
• [implementation] : external attack
  • to provide security ai application L7 against external attack using WAF
  • use DDos protection against L3/L4 attack.
• [implementation] : security in transit
  • data in transit across network can be protected with TLS/SSL
• [implementation] : security at rest
  • data at rest protected with full disk encrptyion with AES256
• [implementation] : account security
  • all account to be manage by identity provider (keycloak)
  • user first need to provide userid and password (salt) to id to get token containing information and hash -> then using the token it can call api gateway which can use public cert from keycloak to check if the provide token from user is correct.before allowing user to access the service.
  • user can also increase security but using multi factor authenication like google 2fa with userid and password.

API Design

API Categories & Complete Endpoint List

1. Authentication & Authorization APIs

2. User Account Management APIs

yaml

3. Wallet & Balance Management APIs

yaml

4. Payment Methods Management APIs

yaml

5. Transaction & Payment Processing APIs

yaml

6. Multi-Currency & Exchange APIs

yaml

7. Fraud Detection & Security APIs

yaml

8. Disputes & Chargebacks APIs

yaml

9. Buyer & Seller Protection APIs

yaml

10. Merchant Services APIs

yaml

11. Notifications & Webhooks APIs

yaml

12. Reporting & Analytics APIs

yaml

13. Compliance & Regulatory APIs

yaml

14. Customer Support APIs

yaml

15. Administration & Platform Management APIs

yaml

16. Integration & Developer APIs

High-Level Design

Enhanced Transaction Safety & Consistency

Improved Security Measures

Enhanced Monitoring & Observability

Compliance & Regulatory Requirements

Key Performance Indicators (KPIs)

Detailed Component Design

1. Transaction Service: The Orchestrator of Financial State

The Transaction Service is the core of the payment system, responsible for maintaining atomicity and consistency across a distributed set of operations. Its primary challenge is ensuring that money is neither created nor destroyed, even in the face of partial failures.

How It Works: The Saga Pattern

Instead of a traditional two-phase commit, which can create locking bottlenecks, this service uses the Saga Pattern. A Saga breaks a transaction into a sequence of independent, compensatable steps. If any step fails, the Saga executes a series of compensating actions to reverse the previous steps and return the system to a consistent state.

The Workflow:

1. Create Pending Record: The saga begins by writing a "pending" transaction record to its database. This acts as a durable log of the intent.
2. Debit Sender: The service calls the Wallet Service to deduct funds from the sender's account. The funds are placed in a "locked" state.
3. Credit Recipient: Only after the debit is confirmed, the service calls the Wallet Service to add the funds to the recipient's available balance.
4. Finalize: The transaction record is updated to "completed."
5. Compensation (Rollback): If the credit step fails, the Saga orchestrator automatically triggers a compensating transaction that credits the money back to the sender, unlocking their funds. The final transaction status is marked as "failed."

How It Scales

• Stateless Processing: The core transaction logic is stateless. This allows us to deploy multiple instances of the service behind a load balancer to handle increased traffic.
• Database Sharding: The transaction database is sharded (horizontally partitioned). A common strategy is to shard by a prefix of the user ID, distributing the load across many database instances.
• Event-Driven Communication: By publishing a transaction.completed event to Kafka, the service asynchronously notifies other systems (notifications, analytics). This decouples the core transaction flow from slower, downstream processes, preventing bottlenecks.

Key Data Structures & Algorithms

• Saga State Machine: The core logic is a state machine that tracks the current step of a transaction, what to do next on success, and which compensation operations to run on failure.
• Idempotency Keys: Every transaction request includes a unique idempotency key. This prevents duplicate processing if a client retries a request due to a network timeout. The service checks this key before beginning a new saga.
• Optimistic Concurrency Control: When updating transaction records, a version number is used. If two updates conflict, only one will succeed, ensuring data integrity.

2. Fraud Detection Service: The Real-Time Guardian

This service acts as a gatekeeper, evaluating the risk of each transaction in real-time (under 100ms) to prevent fraudulent activity. It employs a multi-layered defense strategy.

How It Works: The Multi-Layered Analysis

The service doesn't rely on a single method. It runs three parallel analyses and combines their results into a final risk score.

The Analysis Layers:

Rules Engine (Fast, Deterministic): This layer uses pre-defined business rules for known fraud patterns.

Examples: "Transaction amount > $5,000 for a new user," "Transaction count > 10 per hour," "Transaction from a high-risk country."

Output: A score based on the number and severity of triggered rules.

Machine Learning Ensemble (Adaptive, Probabilistic): This is the intelligent core. It uses an ensemble of models to detect subtle, non-obvious patterns.

Models Used:

Gradient Boosting (XGBoost): Excellent for tabular data, uses hundreds of features (amount, time, user history, etc.).

Isolation Forest: An unsupervised algorithm great for spotting extreme outliers.

LSTM Network: Analyzes sequences of user behavior to detect deviations from their normal pattern.

Output: A probability score indicating the likelihood of fraud.

Graph Analysis (Relational, Investigative): This layer analyzes the transaction as part of a network of users.

It queries a graph database to answer questions like: "Is the recipient connected to known fraudulent accounts?" "Is this a circular payment pattern?" "How many degrees of separation are there between sender and recipient?"

Output: A score based on the risk embedded in the transaction's network.

The Decision Engine combines these three scores using a weighted formula. Based on the final composite score, it makes a decision: Approve, Flag for human review, or Block.

How It Scales

Stateless Model Inference: The feature engineering and model inference steps are stateless. We can scale the service horizontally to manage load.

Specialized Data Stores:

A Redis Cache holds frequently accessed user profiles and recent transaction histories for fast feature calculation.

A Graph Database (like Neo4j) is optimized for traversing relationships between users and transactions.

Async Model Updates: The heavy lifting of model training is done offline. New models are trained on historical data and then deployed to the live service without downtime, often using a blue-green deployment strategy.

Key Data Structures & Algorithms

Feature Store: A central repository that stores pre-computed features (e.g., "user's average transaction amount over 30 days") to speed up real-time inference.

Graph Algorithms: Algorithms like Shortest Path and Community Detection are used to identify money mule networks and organized fraud rings.

Adaptive Ensemble Weights: The weights used to combine the ML models are not static. They are automatically adjusted based on recent performance, giving more influence to the models that have been most accurate lately.