SOURCEENERGY CAPITAL / COMMERCIAL & OPERATING DESIGN
Institutional treasury
platform business model
Build a subscription treasury platform around evidence, approvals and reconciliation. Add institution-executed financial services only after the specific agreements, permissions and release controls are verified.
What to adopt from GSF
GSF’s current homepage presents a technology platform with multi-currency accounts, payments, finance-team roles, reconciliation and recurring plans, with regulated services described as delivered through licensed institutions. Its site states that GSF is not a licensed bank and does not hold client funds. These are GSF’s own website statements; this comparison does not verify its operations or partnerships.
For SourceEnergy Capital, the useful pattern is a single customer experience over clearly separated institution responsibilities. Focus first on corporate treasury and institutional mandates rather than copying GSF’s Malaysian SME rails or personal banking products.
| GSF pattern | SourceEnergy Capital adaptation | Readiness boundary |
|---|---|---|
| Multi-currency business accounts | Consolidated views of externally held accounts, separated by entity and currency | Reference reporting exists; current balances and bank feeds require verified access. |
| Batch payouts and approval roles | Payment preparation, independent review and confirmation reconciliation | Proposed; no live execution channel. |
| Partner-delivered trade finance | Instrument evidence, counterparty coordination and funding-stage tracking | No internal record implies institution acceptance or funded cash. |
| Subscription plans | Recurring software fees plus scoped onboarding and integration | Illustrative pricing; validate willingness to pay and delivery cost. |
| Customer portal and trust information | Client reporting workspace with service status and responsibility disclosures | Authenticated, organization-scoped reporting is implemented. Pilot memberships and real-user acceptance remain pending; payment execution is disabled. |
Brand and customer address
Use SourceEnergy Capital — Treasury & Global Finance for this platform within the SourceEnergy ecosystem. SourceEnergy.Fund is the parent brand website. The proposed customer portal address is treasury.sourceenergy.fund; this local prototype does not configure or publish that subdomain. The contracting legal entity must be identified separately in service agreements.
Customer and value proposition
The initial customer is a corporate finance or treasury team coordinating several entities, currencies or institution relationships. A second segment is an institutional mandate team that needs a traceable review record. Start with one clearly defined segment and jurisdiction during discovery.
The customer pays for less manual reconciliation, fewer unreviewed changes and a clearer distinction between committed capital and deployable cash. Test those outcomes through reconciliation time, exception age, evidence coverage and independently reviewed records. Do not sell access to unverified capital or settlement routes.
Service scope and responsibilities
Treasury visibility
Offer holdings, valuation, liquidity, instrument and mandate reporting. Preserve original currencies, FX direction and freshness, account-level evidence and correction history. The local Treasury Desk already models these controls, but its reference implementation is not proof of a production client service.
Payment operations
The target flow is instruction preparation → independent review → institution submission → institution acknowledgement → settlement evidence → reconciliation. Idempotency keys and duplicate detection protect each submission. A missing or ambiguous confirmation creates an exception; it never silently becomes “settled.” Before connectivity, provide reporting and preparation only.
Trade-finance coordination
Track document intake, counterparty review, instrument authenticity review, institution acceptance, funded proceeds and restrictions as distinct states. SourceEnergy Capital coordinates the workflow; an authorized financial institution decides whether to accept, issue or finance an instrument within its agreement. Face value remains separate from carrying value and funded proceeds.
Institution integration
Use the workspace’s staged route design: Truist onboarding first; UBS only following a relevant agreement; corporate Swift or a service bureau when a validated multi-bank need warrants it. These are onboarding candidates and architectural plans, not asserted partners. No institution logo or “connected” badge should appear without supporting evidence.
| Party | Responsibility | Required boundary |
|---|---|---|
| Customer | Entity information, authorized users, mandates and payment purpose | Customer authority does not grant institution entitlement. |
| SourceEnergy Capital | Workflow software, evidence records, access controls, reporting and reconciliation support | No assumption of fund custody or banking authority. |
| Contracted institution | Accounts, custody, approved rails and financial execution within agreement | Permissions, eligible customers and service terms verified per route. |
| Independent reviewer and domain owners | Release approval, reconciliation sign-off and accounting/legal review within assigned responsibilities | Preparer cannot approve their own material changes. |
Commercial model and scenario
Proposed recurring tiers are Visibility at USD 500/month and Control at USD 1,500/month. Institutional integrations use a scoped agreement. Charge implementation fees only against defined deliverables. Exclude transaction, FX and referral revenue from the base case until commercial terms and jurisdiction-specific permissibility are established.
The initial illustrative case below assumes 12 Visibility customers and 4 Control customers, a USD 100 monthly variable service cost per customer and USD 15,000 in monthly fixed operating cost. Variable cost bundles support, infrastructure and agreed per-customer service costs; the values need supplier quotes and staffing estimates.
Contribution = subscription revenue − variable service costs. Operating result = contribution − fixed costs. Excludes taxes, financing, one-time build costs, institution pass-through fees outside the variable allowance, and implementation revenue. Inputs are temporary and are not saved or transmitted.
At this starting case: USD 12,000 revenue, USD 10,400 contribution and a USD 4,600 monthly operating loss. At the same 3:1 customer mix, each group of four customers contributes USD 2,600/month; six groups, or 24 customers, contribute USD 15,600 and cover the assumed USD 15,000 fixed cost. This is a model threshold, not an acquisition forecast. If costs or mix change, the threshold changes.
Customer acquisition and delivery
Start with direct discovery among corporate treasury teams and approved professional introductions. Demonstrate the reporting workflow using synthetic records. Offer a limited pilot with an agreed scope, named reviewers and success measures. Convert only after the customer can verify the value and the team can cost the service.
Onboarding progresses through scoping, entity and authority review, service eligibility, data-access permission, import validation, reconciliation, user-role review and acceptance. No customer funds need to move for an initial read-only reporting pilot. Assign a product owner, operations owner, security owner, independent release reviewer and accounting owner before any production launch.
Phased launch and evidence gates
| Phase | Deliverable | Exit evidence |
|---|---|---|
| Discovery Weeks 1–2 | Validate the segment, initial jurisdiction, exact service scope and pricing. | Customer interviews, scoped economics and assigned domain reviewers. |
| Reporting pilot Weeks 3–6 | Read-only entity/currency reporting and evidence reconciliation. | Authorized data access, verified user permissions, reconciled sample and acceptance record. |
| Institution onboarding Weeks 6–12 or longer | Secure institution responses, contracts, entitlements and test-route requirements. | Institution-confirmed permissions, reviewed agreements and completed controlled testing. |
| Limited payment release After gates pass | A bounded customer, currency and route scope with enforced limits. | Independent approval, duplicate protection, verified settlement evidence, reconciliation, rollback and incident procedures. |
| Expansion After pilot review | Additional routes, entities or trade-finance coordination. | Fresh route-specific evidence and reviewed economics; no inherited blanket authorization. |
Current baseline and decisions remaining
The read-only portal now authenticates existing SourceEnergy users and checks organization-specific treasury memberships. The scoped reporting RPC was installed on October 6, 2026; no real memberships have been granted. The earlier global-read RLS candidate remains unapplied. Bank channels are unconnected and production settlement remains disabled. See the internal integration record for verification and outstanding pilot requirements.
The model therefore begins with reporting and review. Before commercialization, decide the contracting legal entity, initial jurisdiction, customer segment, institution scope, customer-data permissions, support staffing and final prices. Obtain the relevant legal, accounting and institution reviews for the actual service design; the draft supplies no legal determination.
Measures for the first pilot
- Evidence coverage: reportable records with valid source references divided by all reportable records.
- Reconciliation exceptions: count, age and closure evidence, with missing source data visible.
- Independent review: percentage of material changes reviewed by a separate authorized person.
- Customer value: time to produce a reconciled treasury report before and after the pilot.
- Commercial viability: recurring revenue, actual customer support cost, contribution and retention.
- Release integrity: zero execution outside approved routes, limits and permissions.
Sources and assumption boundary
- GSF Digital Platform homepage, inspected October 6, 2026: service presentation, stated platform status and pricing structure. Website claims are not counterparty verification.
- SourceEnergy Treasury Desk README (internal review document): reference capabilities, staged institution routes and execution status.
- Treasury reporting requirements (internal review document): evidence separation, reviewer controls and open release conditions.
- Truist onboarding packet (internal review document): internal draft questions and secure-transmission gates.
SourceEnergy Capital prices, cost allowances, customer counts, segments and indicative timelines are planning assumptions introduced in this draft. GSF’s prices, partnerships and capabilities are not SourceEnergy Capital facts.
Return to website prototype ←