Traadence's Real Time Trading Software is a production platform core for financial products that need live charts, account funding, order controls, and auditable balances in one operating model. It separates market activity from money movement: chart events can travel quickly over WebSockets, while deposits, withdrawals, transfers, and trade-related balance changes pass through controlled ledger commands. The delivered project includes the user-facing trading workspace, a super-admin console, PSP adapters, risk checks, reconciliation jobs, deployment manifests, and automated tests. It is built for engineering teams replacing fragile balance updates and disconnected services with explicit transaction states, replayable events, and reviewable access controls.
Why Financial Platforms Fail Under Real Load
A trading interface can appear healthy while its financial core is drifting. Duplicate PSP callbacks may credit a wallet twice, two withdrawal workers may reserve the same funds, and delayed market events may leave a chart out of sequence. The platform treats these as domain failures rather than generic application errors. Every money command carries an idempotency key, every balance change creates balanced ledger entries, and every privileged action records actor, reason, timestamp, and before-and-after state. This makes recovery possible without editing balances directly.
Core Features
| Feature | Description |
|---|---|
| Dual Wallet and Double-Entry Ledger | Mixed funds create reconciliation gaps. Cash and trading balances are separated, while every movement posts matched debit and credit entries inside one database transaction. |
| Idempotent Deposit Processing | Repeated provider callbacks can duplicate credits. Signed webhook events are normalized, deduplicated by provider reference, and advanced through pending, confirmed, or rejected states. |
| Controlled Withdrawal State Machine | Concurrent withdrawal attempts can overspend available funds. The platform atomically reserves balance, applies approval rules, dispatches the PSP request, and releases or settles the reservation. |
| Pre-Trade Risk Evaluation | Orders should not reach execution after a limit is breached. The engine checks exposure, instrument status, account permissions, order size, drawdown thresholds, and session controls before acceptance. |
| Live Chart Data Feed | Polling produces stale or uneven chart updates. A normalized market-data service publishes ordered bars, quotes, and status changes to the browser through authenticated socket channels. |
| Super-Admin Control Plane | Operational teams need intervention without direct database access. Role-scoped screens manage users, wallet holds, provider events, risk rules, instruments, and documented manual reviews. |
| PSP Adapter Boundary | Provider-specific payloads otherwise leak across the codebase. Each integration maps signatures, status codes, currencies, retries, and settlement references into one internal payment contract. |
| Reconciliation and Audit Trails | Silent drift can survive for days. Scheduled jobs compare provider settlements, wallet totals, and ledger postings, then open an exception with immutable evidence for review. |
Architecture Built Around Financial Invariants
The application uses NestJS WebSocket gateways for authenticated live channels and modular domain boundaries. PostgreSQL transaction isolation protects ledger writes, reservations, and command state. Redis Streams carries ordered domain events to chart, notification, and reconciliation consumers without making Redis the source of financial truth. TradingView Advanced Charts renders the market workspace against the platform's own datafeed. Kubernetes autoscaling scales stateless API and socket workloads independently from ledger workers.
| Boundary | Implementation decision | Reason |
|---|---|---|
| Command side | CQRS handlers validate permissions, risk rules, current state, and idempotency before committing. | Money-changing paths remain explicit and testable. |
| Event side | An outbox record is written with the business transaction, then published asynchronously. | A committed ledger change cannot disappear because a broker or queue was unavailable. |
| Balance model | Available, reserved, and posted amounts are derived from controlled entries and snapshots. | Workers never overwrite a single mutable balance field as their only record. |
| Recovery | Failed consumers retry with bounded backoff and dead-letter review; commands are safe to replay. | Operational recovery does not require a second financial effect. |
Security and Payment Controls
The API model is reviewed against the OWASP API Security Top 10, with object-level authorization, rate limits, signed callbacks, short-lived access tokens, refresh-token rotation, and separate admin scopes. PSP handling follows the control direction in the PCI DSS document library: card data remains with compliant providers, secrets are isolated, and logs avoid sensitive account values. Ledger, reconciliation, and incident procedures are aligned with the safety and auditability principles described in the CPMI-IOSCO PFMI. These references are design baselines, not claims that deployment alone confers regulatory certification.
Repeatable Performance and Recovery Checks
The repository includes staging tests with explicit pass criteria rather than vague speed claims. Results depend on infrastructure size, provider latency, market-data rate, and database configuration, so each deployment reruns the profile before release.
| Scenario | Acceptance target | Verification method |
|---|---|---|
| Chart fan-out | 10,000 concurrent socket sessions with p95 publish delay below 150 ms. | Ramp connections in stages, publish sequenced bars, and compare server timestamps with browser acknowledgements. |
| Wallet commands | 500 commands per second for 15 minutes with no unbalanced ledger transaction. | Mix deposits, transfers, holds, releases, and withdrawals while validating debit-credit equality after every batch. |
| Duplicate callbacks | 1,000 repeated provider events produce one financial effect per external reference. | Replay identical and reordered payloads, then verify command keys, payment states, and ledger entry counts. |
| Consumer recovery | A restarted worker resumes within 60 seconds without losing or duplicating committed events. | Terminate consumers during processing, restart them, and compare outbox, stream offsets, and projected state. |
Use Cases
- Launch a consumer trading product with live charts, account controls, and a financial core that can be audited without reconstructing history from application logs.
- Add a second wallet for promotional, trading, or restricted funds while preserving clear transfer rules and separate reconciliation totals.
- Connect a new payment provider through one adapter contract, keeping webhook verification, retries, currencies, and settlement references outside wallet logic.
- Give operations staff controlled tools for holds, reviews, risk changes, and reconciliation exceptions without granting production database access.
- Scale chart traffic and API reads independently while keeping balance-changing commands serialized around financial invariants.
Project Directory
trading-platform/
├── apps/
│ ├── api/
│ │ └── src/
│ │ ├── main.ts
│ │ ├── app.module.ts
│ │ ├── auth/
│ │ ├── orders/
│ │ ├── risk/
│ │ ├── wallets/
│ │ ├── payments/
│ │ ├── market-data/
│ │ └── admin/
│ ├── web/
│ │ └── src/
│ │ ├── app/
│ │ ├── components/
│ │ ├── charts/
│ │ ├── admin/
│ │ └── wallet/
│ └── workers/
│ ├── outbox.publisher.ts
│ ├── reconciliation.worker.ts
│ ├── payment-callback.worker.ts
│ └── market-bar.worker.ts
├── packages/
│ ├── ledger/
│ │ ├── ledger.service.ts
│ │ ├── posting.rules.ts
│ │ └── balance.snapshot.ts
│ ├── contracts/
│ │ ├── payment-provider.ts
│ │ ├── market-data.ts
│ │ └── domain-events.ts
│ └── security/
│ ├── authorization.guard.ts
│ ├── webhook-signature.ts
│ └── audit.interceptor.ts
├── database/
│ ├── migrations/
│ ├── seeds/
│ └── schema.sql
├── tests/
│ ├── ledger-invariants.spec.ts
│ ├── duplicate-callbacks.spec.ts
│ ├── withdrawal-races.spec.ts
│ └── socket-load/
├── deploy/
│ ├── k8s/
│ ├── helm/
│ └── observability/
├── docker-compose.yml
├── package.json
├── README.md
└── .env.example
How to Run Trading Sessions Using Traadence's Real Time Trading Software
Download & Set Up the Project
Download, set up, and install Traadence's Real Time Trading Software to get the project running. If you hit any difficulty, contact us here.
Open the Admin Console
Sign in with an administrator role, then verify the market-data connection, enabled instruments, PSP status, wallet policies, and current risk-rule version.
Configure the Session
Choose the trading account, instrument set, order limits, exposure ceiling, drawdown threshold, wallet funding source, and chart resolution used for the session.
Start and Review
Select Start Session to enable trading. The workspace returns live charts, order status, wallet movements, risk rejections, and reconciliation exceptions in their assigned panels.
Teams extending provider adapters, risk rules, or deployment controls can use Traadence's trading platform development services for integration, hardening, monitoring, and ongoing maintenance.
Questions
What is a trading platform?
A trading platform is the software layer that connects market data, account state, order workflows, risk controls, and operational administration. In a real-money product, the interface is only one part; wallet consistency, authorization, reconciliation, event recovery, and audit trails determine whether the platform can be operated safely.
Is TradingView real time in this platform?
The chart can update in real time when the deployment supplies a licensed live data source and publishes updates through the platform datafeed. TradingView provides the charting component, not the market-data entitlement, so exchange permissions, vendor agreements, symbol mapping, and timestamp quality remain deployment responsibilities.
How does TradingView work in this platform?
The frontend embeds Advanced Charts and connects it to a custom datafeed service. Historical bars come from the platform's market-data store, live bars arrive through authenticated socket channels, and order or position overlays are drawn from the user's authorized account state.
What features should a real-money trading platform include?
A real-money platform should include strong identity controls, explicit order validation, tamper-evident audit records, an append-only double-entry ledger, idempotent payment processing, reconciliation, fraud controls, observability, and tested failure recovery. It should also isolate market-data delivery from balance-changing commands so traffic spikes cannot weaken financial consistency.