Stakeholder Briefing

The IF Platform

A plain-language overview of what we are building, where the project stands, and the decisions we need from you.

Prepared for the Institutional Funding team · a one-page-at-a-time read (~10 minutes). A full technical specification exists separately for the engineering team.

What IF is, in plain terms

IF is a platform for a proprietary trading firm — a business that funds skilled traders with the firm's own capital and shares in the profits they make.

The customer journey is simple to describe. A trader pays for and takes a challenge: a test trading account with clear rules — reach a profit target without losing more than a set limit. Pass the challenge, and they receive a funded account and can withdraw their agreed share of the profits (the profit split). Our platform runs that entire journey end to end — the purchase, the trading account, the risk checks, and the payouts.

We are building the first real version of this platform. An earlier build proved the concept but never became a finished, shippable product; we are using it only as a reference for what the system should do, and building the real thing on solid foundations from day one.

What we are building

One clean, modern software system with two faces:

A customer portal — where traders sign up, buy a challenge, follow their account, and request payouts. It works like an app they can install on their phone.
A back office — where your team manages accounts, reviews and approves payouts, monitors risk, and configures the products you sell.

Because it handles real money, three protections are built into the foundation — not added on later:

A customer can only ever see their own money and account.

Never anyone else's — enforced at the deepest level of the system, not just in the screens.

A payout can only be sent by your staff.

It is structurally impossible for a customer to trigger a payment to themselves.

The same payout can never be sent twice.

Even if a server crashes in the middle of sending, the money goes out exactly once — or not at all, flagged for a person.

What makes it stand out

Most prop-firm dashboards are web pages: they open only in a browser, and you reload to see anything new. IF's trader side works like a real app. A trader installs it on their phone. Balance and drawdown update on screen as they trade, without a reload. And the moment something matters — a challenge phase passed, an account funded, a payout paid — a push notification arrives on the phone.

The payout machinery is built so a payout goes out once, or not at all and flagged for a person to check — never sent twice, even if a server fails mid-payment. (How completely this holds end to end depends on how each payment provider confirms and de-duplicates a transaction, one of the provider facts still to pin down.) What traders worry about most is being paid, in full and on time, and that reliability is built into the foundation rather than watched for by hand.

IF owns the platform instead of renting one of the white-label templates competitors run, so it can change and extend it as the business needs, rather than waiting on a vendor's roadmap.

How the industry works, and where IF fits

Prop firms run on a repeatable loop: they sell evaluation challenges, fund the traders who pass, monitor those traders' risk, and pay out a share of the profits. The trading itself happens on a platform the firm connects to — usually MetaTrader 5 (MT5).

Most firms assemble the same parts: MT5, an identity and KYC vendor, payment and payout providers, and a dashboard or back office to tie it together. Many buy this as a packaged "prop-firm-in-a-box." That is the fast way to launch, but the software is rented and shared with competitors, and it only does what the vendor lets it do.

The market is young and crowded. Traders weigh price, profit split, and account rules, but the deciding factor for many is whether a firm actually pays, in full and on time. That makes payout reliability, and what the trader sees on their phone every day, real competitive ground.

IF builds its own platform instead. Owning it is what lets IF change payout handling and the trader app on its own schedule, where a firm on rented software cannot. A competitor could build too; most run rented platforms and do not. The trade-off is honest: building costs more time up front than renting.

Why the foundation comes first

A few decisions in a software system are cheap to change; most are not. Features are cheap — you can add a report, a screen, or a new challenge product long after launch and nothing else has to move. The foundation is different: the shape of the data, how money moves from an account to a payout, and how one customer is walled off from every other one. Change those later and you are not editing a feature; you are reworking the parts that touch money while the system is live and holding real balances.

That is why the first three to four weeks go into the foundation, before feature-building starts. Get it wrong and every feature inherits the flaw; get it right and features become fast and safe to add. This design has already been through several rounds of adversarial expert review, which caught and fixed real money-handling flaws while it was still a document. That time is the cheapest insurance in the project: a flaw fixed in a design costs a revision; the same flaw after launch costs a rebuild.

Where the project stands

The design is complete and independently stress-tested — the adversarial reviews in the previous section are part of why we can say that.

The honest status: the plan is sound and close to build-ready. To actually start building, we need a small set of business, legal, and provider facts that only your team can give us. Those are the questions in the next section. A few of them decide whether the first version can go fully live or must run in a test-only mode at first — so they matter.

What we need from you

These are the decisions and facts that unblock the build. Terms in italics are explained in the glossary at the end.

Legal & complianceEssential

In which country or countries will IF operate, and under what regulations?

Why it matters: it shapes everything below and whether a licence is required to pay customers.

Before paying a customer, are you legally required to verify their identity (KYC) and screen them against financial-crime and sanctions lists (AML)? Can the first version pay anyone without this, or must it come first?

Why it matters: if it is required, it must be built before real payouts — and the first version may have to run in a test-only mode until it and any licence are in place. This can change the launch plan.

The product you are sellingEssential

What are the exact challenge products and their rules — account sizes, profit target, maximum loss allowed (drawdown), the profit-split percentage, how often payouts happen, minimum trading days, and any refunds or retakes?

Why it matters: this is literally what you sell, and it decides how much money leaves the firm and to whom. It is not yet defined anywhere.

Money & currencyEssential

What currency is each part in — the challenge price, the trading account, and the payout? Are any of them ever different?

Why it matters: if they differ, there is a currency-conversion step that must be recorded precisely, or the books will not reconcile.

Where does payout money physically come from — the broker, or IF's own funds — and are funded accounts traded on a live market or a demo one?

Why it matters: it changes how a funded account is created and who absorbs the loss when a trade or a payment goes wrong.

Risk & fraudImportant

If a customer pays by card and later reverses that payment (a chargeback) after we have already paid them a profit, what is your policy — absorb the loss, or claw it back?

Why it matters: this is the classic prop-firm fraud, and card reversals can arrive months later. It is a business risk-appetite decision, not a technical one.

Should approving a payout and actually sending it require two different staff members? How many staff will there be, and what access will they have?

Why it matters: one compromised or dishonest staff account is the most direct route to stolen money; a two-person rule is the standard defense.

Operations & resilienceImportant

If a server fails, how much downtime and how much data loss is acceptable (RPO / RTO), and will someone be available to respond at any hour? Will you fund off-site backups?

Why it matters: the lean, low-cost setup trades some resilience for savings — this decides how far to go, and it is a cost trade-off for you.

Is running everything on your own servers (rather than a large cloud provider) a firm requirement or a cost preference?

Why it matters: without a big provider's built-in shield, more protection against online attacks has to be built and maintained by us.

GrowthGood to know

How central are affiliates (introducers who refer customers) to your growth, and do you need them at launch?

Why it matters: prop-firm growth is usually affiliate-driven; if it is a day-one need, we build that part earlier.

For your technical or provider contacts — not a business decision

A few questions are integration details about your MT5 trading platform and your payment and payout providers — specifically, how each one confirms a transaction and prevents duplicates. These decide exactly how the "never pay twice" machinery is built. Your engineers, or the providers' own documentation, will have the answers; they do not need to be resolved in this meeting.

Questions you may be asked — and how to answer

"Why build new instead of improving what you have?"

The strong, simple answer: nothing in use is being thrown away. The earlier build was a prototype that proved the idea but never became a real, shippable product. We are building the first proper version, with the safeguards a real-money system needs built in from the start rather than bolted on later. There is no working system being discarded — this is "build it right the first time."

"Is it secure enough for real money?"

Answer: the three protections in section 2 are structural — a customer can only see their own account, only staff can send a payout, and no payout can go out twice. On top of that sit standard safeguards (identity checks before payout, limits on repeated attempts, and the two-person payout rule if you want it). A dedicated security-hardening review is scheduled before going live. We are being candid about the trade-offs rather than claiming perfection.

"How long will it take, and what will it cost?"

Answer: around six months to a complete, testable platform, and roughly nine months to be live in production with real payouts (see section 9). The path to going live is set as much by licensing and compliance as by the software — the code is not the slowest part.

"Who builds it — and can you trust AI to write a money system?"

Answer: the work is done as pair programming: senior developers working alongside AI tools to move faster. This is not "AI builds it on its own" — a human writes, reviews, and is accountable for every part, and especially owns the money-handling and security-critical logic. AI accelerates the routine work; experienced people stay in control and make the decisions.

Timeline & how the work is done

A realistic schedule for a real-money, regulated platform of this kind — grounded in what these systems genuinely take. The deep integration with the trading platform, the identity and payment providers, the risk logic, testing, and security all take real time. Two milestones to hold us to:

~6 months

A complete, testable platform. Every part built and working end to end — challenge purchase, funded accounts, automatic pass/fail rules, payouts, notifications, and the installable customer app — running in a closed test with no real money moving yet.

~9 months

Live in production. Security-hardened, backups and monitoring in place, identity and compliance checks live, and open to real customers with real payouts — subject to the licensing answers above.

The three things that set the pace sit outside the code: the trading-platform and payment/payout integrations, the identity-verification vendor, and licensing. The software itself is the faster part — which is why the path to going live is a compliance date as much as an engineering one.

How the coding is done

Development is done as pair programming — senior human developers working alongside AI tools to move faster. This is not "AI builds it on its own": a human writes, reviews, and is accountable for every part, and especially owns the money-handling and security-critical logic. AI accelerates the routine work; experienced people stay in control and make the decisions. That combination is exactly what makes a six-to-nine-month schedule realistic for a system of this scope, without cutting corners on the parts that move money.

The very first step after this meeting

Before committing to the full build, we run a few quick technical trials — connecting to the real trading platform, testing the payment and payout providers, and proving the core money flow end to end. These turn today's biggest assumptions into evidence and remove most of the technical risk up front.

The technology, in more detail

Software that moves real money should be built from the most boring, well-understood parts that do the job. Every piece here was chosen because it is proven in production elsewhere and well-understood enough that AI tools handle the routine parts with few mistakes, under human review — not because it is new. Nothing here is exotic, and that is the point: fewer surprises, and a small senior team can hold the whole thing in their heads.

TypeScript, front to back — one language, one codebase, fewer seams between parts to get wrong.
PostgreSQL — a database with decades of use behind it, enforcing "you only see your own data" at its core.
Vue — one phone-installable customer app and a back office built from the same parts, so a fix in one place carries to both.
Redis & BullMQ — the engine for background work like payments and account syncing, with a permanent record so a payout is not sent twice, even if a job restarts.
Live updates over a persistent connection — balances and statuses refresh on screen on their own.
Self-hosted, reproducible from a single recipe — full control and predictable recovery, at the cost of more upkeep falling to us rather than a managed cloud.

Glossary

Prop firmproprietary trading firm: A company that funds skilled traders with its own money and shares the profits, rather than managing outside clients' money.
Challengeevaluation: A paid test account with rules a trader must meet (a profit target without breaching a loss limit) to qualify for funding.
Funded account: The real trading account a trader receives after passing the challenge, trading the firm's capital for a share of the profit.
Profit split: The agreed share of trading profits the trader keeps (for example, 80% to the trader, 20% to the firm).
Drawdown: The maximum a trader is allowed to lose — either in a single day or overall. Breaching it fails the account.
Payoutwithdrawal: Money paid out to the trader — their profit share. The most sensitive action in the system, because it is irreversible.
KYCKnow Your Customer: Verifying a customer's real identity (ID documents, etc.) before doing business — a legal requirement in most regulated markets.
AMLAnti-Money-Laundering: Rules and checks (including screening customers against sanctions and financial-crime lists) to prevent the business being used to launder money. Usually paired with KYC before any payout.
Chargeback: When a customer reverses a card payment through their bank. It can happen months later — a real fraud risk if the trader has already been paid a profit.
MT5MetaTrader 5: The industry-standard trading platform on which the actual trading accounts run. Our system connects to it to create accounts and read balances.
Affiliateintroducer / IB: A partner who refers customers in exchange for a commission — typically the main growth channel for a prop firm.
RPO / RTOrecovery point / time objective: Two resilience targets: how much recent data you can afford to lose in a failure (RPO), and how long you can afford to be down before recovery (RTO).
Self-hoston your own servers: Running the software on rented servers you control, rather than a large managed cloud — cheaper and fully in your control, but more of the upkeep and protection falls to us.
Sandbox / test mode: Running the full system with no real money moving — used to operate safely before licences and identity checks are in place.