AI Investments, General Investment and Forex Investment

This platform sells three separate earn products that look the same from a distance. All three publish plans, attach durations to them, take a principal, and settle at maturity as WIN, LOSS or DRAW. Two of them share the same HTTP route, distinguished only by a type field. None of them shares a table, a plan, an admin screen, a switch or a cron job with the others.

The cost of confusing them is not cosmetic. Editing a rate on the wrong console does nothing to the positions you were looking at, turning off the wrong switch stops the wrong product, and the admin "mark completed" action behaves differently on each of the three — on one of them it pays the customer, on another it writes a column and pays nothing.

The comparison

The three permission families are disjoint. A role holding every *.investment* key can see none of the AI console and none of the forex console, and vice versa. Grant them separately.

The three enable switches do different jobs

AI Investments is switched at /admin/system/extension, the ai_investment row. It is a true master switch: it controls the admin menu entry, the purchase tab in the trade panel, and whether the hourly settlement task is registered at all. Turn it off and running investments stop settling for as long as it stays off. This is covered in full on Configuration surface.

General Investment is switched by a platform setting, not an extension row:

It lives at Admin → System → Settings → Features → Investment. Three things read it: the purchase endpoint, the customer menu, and the footer's Products-section Investment link, which disappears along with the menu entry when you switch it off. Nothing else does — in particular, processGeneralInvestments does not consult it, so switching the product off stops new money coming in and leaves existing positions settling normally. That job is a core job: it is registered unconditionally and appears on /admin/system/cron as Process General Investments on every install, whether or not the setting exists. The fresh-install trap where the toggle reads on over a row that was never written is documented on General Investment: enable and configure.

Forex Investment is switched at /admin/system/extension, the forex row, which gates the whole forex addon — accounts, deposits, withdrawals and signals as well as investments. processForexInvestments is registered under the forex category and is deregistered with the extension.

The three KYC features are independent

Each product asserts its own feature id, and the level builder lists them under Investment at Admin → CRM → KYC:

That last row is the one to read twice. The shared endpoint chooses the feature from the type it was given, precisely so a level you denied invest_forex cannot open a forex position through the general product's door.

All three gates are inert unless both kycStatus and kycFeatureEnforcement are on. kycFeatureEnforcement is off by default, so on a stock platform none of the three is checked.

The shared routes, and the type field

Two of the three products are served by one pair of endpoints:

The matching reads — GET /api/finance/investment and GET /api/finance/investment/{id} — also take ?type=. The accepted values are general and forex, matched case-insensitively. A missing value is refused with 400 Invalid investment type on all four handlers, but an unrecognised one is not handled evenly. Only the two writes reject it cleanly: POST guards with an if (!model) check after its switch, and DELETE has a default: that throws, both giving that same 400. Neither read does. The single-investment read's switch has no default:, so ?type=bogus leaves the model undefined and the query throws a TypeError — a 500, not a 400. The list read does have a default: on its main switch, but a request carrying a type and no page parameter never reaches it: that one is answered by the active-investments branch, whose own switch has no default and fails the same way. A 500 from either read is therefore usually a typo in type rather than a platform fault.

Two companions on the same prefix are general-only and take no type at all: GET /api/finance/investment/plan reads investment_plan, and GET /api/finance/investment/stats counts investment rows. Neither ever returns a forex or AI figure.

AI Investments is not on this route family. It has its own prefix, /api/ai/investment/…, and no type switch. The type field on its purchase body means something else entirely — it is the wallet type, SPOT or ECO, which is why an AI investment row carries type = SPOT while a general one carries no such column at all.

The forex branch of the shared route also skips checks the addon's own route runs: it does not consult forex_plan_duration, so any duration can be paired with any plan; it does not check plan.status, so a withdrawn plan still sells; it does not require the terms acceptance the forex route demands; and it does not run the forex fraud detector.

One rule that exists only on the shared route

POST /api/finance/investment refuses a second simultaneously-ACTIVE investment in the same plan, with 400 Already invested in this plan. This is enforced in application code, not by a database constraint, and it applies to both branches of that route.

Neither POST /api/ai/investment/log nor POST /api/forex/investment has any such rule. A customer can hold any number of concurrent AI investments in one plan, and any number of forex investments in one plan. If you are sizing your exposure, note that a plan's maxAmount caps a single ticket on all three products and nothing caps the book.

Maturity is computed three different ways

This is the divergence that produces "my term is over and nothing happened" tickets, because two of the three products treat a month as 30 days and one treats it as a calendar month.

A 12 MONTH term therefore matures after 360 days on AI Investments and after a full calendar year on General Investment — five or six days apart on identical-looking plans.

Two operational consequences:

• A general or forex maturity date can be edited; an AI one cannot. The general console's edit form on /admin/finance/investment/history writes endDate as a plain column, and the cron honours it. AI Investments has no such column, so the only way to move an AI maturity is to settle the investment early from the Investment Logs status action.
• All three settle up to an hour late. Every one of the three jobs runs on a 60-minute period, and none of the periods is configurable. A term that ends at 14:05 is paid on the next run. AI Investments additionally settles a customer's matured positions in-line when they open their own list; the other two do not.

Settlement: what is the same, and what is not

The payout arithmetic is identical on all three. With amount as the principal and roi as the absolute return:

A LOSS is therefore not a total loss anywhere in this platform unless the configured rate reaches 100%. On all three products the customer gets max(0, principal − roi) back and the forfeited slice is booked as platform revenue through the same shared helper, which credits it to the oldest Super Admin's wallet. A WIN books the profit paid out as a platform loss. A DRAW books nothing. The adminProfit rows are typed AI_INVESTMENT, INVESTMENT and FOREX_INVESTMENT respectively, and are visible on /admin/finance/profit.

What differs is where the money lands and what it leaves behind:

• AI Investments credits the wallet as an AI_INVESTMENT_ROI transaction with reference <id>_roi, resolving the wallet from the original funding transaction first and from (user, type, quote currency) second.
• General Investment credits the wallet as an INVESTMENT_ROI transaction with reference <id>_roi, resolving the wallet from the plan's currency and walletType.
• Forex Investment moves forexAccount.balance directly and writes no transaction row at all. A settled forex investment is invisible in the customer's transaction history and in /admin/finance/transaction; the only records are the forex_investment row itself and the adminProfit entry.

The admin status actions are not equivalent

Three consoles, three "set the status" buttons, three different behaviours. This is the single most expensive confusion between the products.

Note also that AI completion pays the full profit regardless of how much of the term has elapsed. There is no pro-rating in any of the three products.

/investment is the General Investment product

The routes at /investment, /investment/plan, /investment/portfolio and /investment/[id] belong to core's General Investment feature and read /api/finance/investment. They have nothing to do with the AI Investments addon: a plan created at /admin/ai/investment/plan never appears there, and the admin shortcut from those pages points at /admin/finance/investment/plan.

/investment/dashboard and /investment/history are redirect stubs kept alive because emails, notifications and the main menu have linked to them for years; both land on /investment/portfolio.

Where to read next

For this addon, continue with Creating plans, Durations and The investment lifecycle, or Admin screens for the consoles.

For the other two products: