Draft — Not for Decision-Making
This document merges Beyond Forecasting v2 and Palm Vision Pillars into a single strategic bets document with comparable revenue numbers for stack-ranking. All revenue figures are back-of-envelope or market comps — not validated with sales. Effort estimates are product-side only — not engineering-validated.
Beyond Forecasting v3: Strategic Bets — Merged & Stack-Ranked¶
Authors: Gurjit Pannu & Emma Sjöström | Date: 2026-03-11 | Status: Draft for management discussion
Purpose: Merge Palm's product-level bets (v2) and company-level pillars (Vision Pillars) into a single document where all five bets can be stack-ranked against each other on revenue, evidence, effort, and practicality. Provide filled prioritization assessments (blank in v2) and a recommended sequencing.
Agreed near-term focus: Intelligence layer (Scenario A). Each bet is assessed across all levels so the full progression is visible, but Level 1 (intelligence) is where we start.
1. Strategic Foundation¶
The approved Treasury AI thesis defines how we build. The five bets below define what we build — the application of the thesis to specific treasury domains.
Each bet is assessed through the thesis's lens:
| Thesis Concept | How It's Applied Here |
|---|---|
| Three pillars of trust (correctness, structural safety, contextual alignment) | Each bet has a trust assessment — can we deliver accurate, governed, customer-specific answers? |
| Three technical layers (agent orchestration, context engineering, knowledge engineering) | Each bet's effort estimate uses these layers instead of vague "weeks" |
| Workflow-led approach ("let failures define what to build") | Each bet requires a concrete customer workflow — no abstract market opportunities |
| Knowledge engineering as moat (semantic layer: 16.7% → 83%) | Each bet identifies what institutional knowledge Palm accumulates that's hard to replicate |
2. The A/B/C Framework¶
Each bet can be pursued at three levels of ambition. The agreed near-term focus is Scenario A (intelligence layer), but each bet below is assessed across all levels so the full progression — and what it actually takes to go deeper — is visible.
| Scenario | Palm's Role | What We Build | Licensing | Revenue Model |
|---|---|---|---|---|
| A: Intelligence | Analytics & visibility | Aggregate data, normalise, surface insights and recommendations. No money moves through Palm. | None required. Pure SaaS. | SaaS subscription |
| B: Orchestration | Marketplace / order router | Initiate actions — route orders, trigger payments, direct investments — licensed partner executes. | Lighter (introducing broker, tied agent). | Transaction margin + referral fees |
| C: Execution | Principal / direct venue | Hold licenses, take regulatory capital, own transactions end-to-end. | Full (CFTC, SEC, MiCA, FCA). | Execution spread |
Scenarios are additive — each builds on the one before. Scenario A is the natural starting point: fastest to ship, zero regulatory burden, and meaningful revenue on its own. B and C layer on top as the market, licensing, and customer demand justify the investment.
Note: Not every bet maps cleanly to A/B/C. FX and Tokenized Treasury have clear progression across all three. Bridging and IC Intelligence are primarily intelligence bets where execution isn't really the end state. Bank Connectivity is infrastructure that enables other bets' progression — it doesn't have its own A/B/C. Each bet section uses the framing where it fits and drops it where it doesn't.
Scenario A alone — zero licensing, pure SaaS — represents an estimated $2.6M–$8.5M incremental ARR across all pillars (from Vision Pillars doc, back-of-envelope).
3. Table Stakes¶
These are hygiene — needed to sell upmarket, but not strategic bets. Brief treatment only.
| Area | Status | Notes |
|---|---|---|
| Scenario Modelling | WIP — percentage-based adjustments shipping | Universal demand. Key differentiator. Multi-scenario comparison next. |
| Governance & Decision Intelligence | Needed | Policy enforcement, audit trails, approval workflows. The "thick middle" itself. Required for any bet to reach enterprise. |
| Basic Debt/Investments | WIP — investments shipping | Maturity ladders, rate tracking, facility monitoring. Natural data model extension. |
| IC Categorization | WIP — improvements underway | Entity-level accuracy prerequisite for IC intelligence bet. |
| Reporting & Shareability | Ongoing | Export, stakeholder views, audit logs. |
| Enterprise ACL | Needed | Role-based access, entity-level permissions. |
4. The Five Bets¶
Bet 1: FX Risk Intelligence¶
The bet: Own the corporate FX intelligence workflow — from "what am I exposed to?" through "what should I do about it?" to (eventually) "do it for me."
Why this is #1: Strongest evidence base (6+ sources), highest ACV uplift potential, lowest effort to start, ON ready to co-develop, and the strongest equity story for the company. At the intelligence layer alone, there's a viable SaaS business. The deeper levels are optionality.
At a Glance¶
| Level 1: Exposure Visibility | Level 2: Decision Intelligence | Level 3: Execution & Governance | |
|---|---|---|---|
| What they get | See net FX exposure across entities + time horizons. Run rate scenarios. | Hedging recommendations, bank rate benchmarking, acquisition FX planning. | Execute hedges from Palm. Measure hedge effectiveness. Full audit trail. |
| Revenue model | SaaS module (part of $100K+ deals) | SaaS higher tier ($80–150K standalone) | SaaS + orchestration fees or charge banks for access to customer flow (360T/FXall model) |
| Effort | Low — new views on existing data (4–6w est.) | Medium — knowledge engineering for policies + recommendation logic | High — multi-year. Partner integrations, hedge accounting engine, licensing. |
| Confidence | High | Medium — need to understand competitor depth | Low — licensing unclear, monetization unresolved |
| What's hard | Is visibility alone worth paying for, or perceived as table stakes? | Recommendation quality — wrong hedge advice destroys trust. How to get policy data into system? | Hedge accounting (IFRS 9 / ASC 815). Licensing (CFTC, FCA). Agent threat to execution layer. |
We are proposing to start at Level 1. Level 2 follows naturally. Level 3 is optionality — and faces hard questions about licensing, monetization model, and whether AI agents commoditize execution before we get there.
What outcomes will people pay for?
- Level 1: "I know what I'm exposed to" — visibility. Pay for clarity across entities/currencies.
- Level 2: "I'm making better decisions" — benchmarking shows you're overpaying X bps, recommendations save Y% on FX costs.
- Level 3: "I'm paying less for FX" — best execution across banks, reduced spreads. Or: free to customer, banks pay Palm for flow.
| Scenario A revenue | $1M–$3.2M (Vision Pillars, back-of-envelope) |
| ACV per customer | $80–150K standalone; $150K+ bundled with forecasting |
| Customer to build with | ON (active — kicking off risk management, 2027 go-live) |
| Second customer | Personio (defined FX policy, 3 months coverage) |
| Evidence | Strong — 6+ transcript sources |
| Equity story | Highest impact — "disrupting FX risk management" narrative |
Key unknowns
- All revenue numbers are back-of-envelope — need sales validation (Christian/Gurjit)
- We don't understand MillTechFX's ~$50K analytics product well enough — could be direct competitor at Level 1-2
- Kantox pricing and positioning unknown
- ON case study needed: model contract value across FX + investments + payments at Scenario A (management request)
- Effort estimates are product-side only — not engineering-validated
Detailed Level Descriptions
Level 1: Exposure Visibility (the skateboard)
What the treasurer gets: Open Palm → see net currency exposure across all entities and time horizons → run FX rate scenarios → see P&L impact of rate movements → export for CFO.
What we build: Currency-denominated forecast views, multi-currency balance visualization, FX rate scenario overlays (building on existing scenario engine), bottom-up exposure analysis from forecast data.
Data readiness is high — transaction data with currency info already exists in Palm. Need: market rate feed API integration.
Main question: is "see your exposures" valuable enough standalone, or is it perceived as table stakes? Enterprise complexity makes it genuinely hard to get a consolidated, accurate view across entities, currencies, and time horizons — same argument as forecasting. But we need to validate this with customers.
Level 2: Decision Intelligence
Beyond "here are your exposures" to "here are the decisions you should take." Hedging recommendations with rationale, bank rate benchmarking ("you're paying X for EUR/USD, market is Y"), acquisition FX planning, IC loan FX centralization decisions.
What we build: Policy encoding (hedge ratios, counterparty limits, tenor preferences), rate benchmarking engine, recommendation logic, decision memo generation.
The hard problem is recommendation quality. A hedging recommendation that's wrong or naive destroys trust instantly. Need to encode customer-specific policies accurately. How do we get FX policy data into the system? File upload? Structured intake? This is the knowledge engineering challenge — same pattern as the thesis's "16.7% → 83%" with semantic layers.
Research needed: deep dive into Kantox (analytics or execution-focused?), how enterprise teams currently get FX decision support (Chatham advisory? Bloomberg? Internal models?), what "hedge recommendation" actually means in practice (instruments? timing? notional amounts?).
Level 3: Execution, Measurement & Governance
Execute hedges from Palm (via partner rails or eventually direct). Measure hedge effectiveness (IFRS 9 / ASC 815 compliance). Full audit trail from exposure identification through execution to accounting treatment.
Two possible monetization models — open question:
(a) SaaS + orchestration fees — charge customer for platform, take referral/routing fee from execution partner.
(b) Charge the banks — 360T and FXall are free to treasurers. They charge banks for platform access because being where the treasurer trades means winning more flow. Palm could do the same.
Licensing: Scenario B (orchestration via partners) = lighter licensing (introducing broker, tied agent). Scenario C (direct execution) = full licensing (CFTC swap dealer, SEC broker-dealer, FCA authorisation) — significant capital and compliance. Not a near-term path.
Hard problems: Hedge accounting is genuinely complex (effectiveness measurement, designation/de-designation, cash flow vs fair value hedges). Agent threat: OpenAI Frontier-type agents on top of existing FX platforms could commoditize execution. But most legacy platforms don't even have public APIs — agent-based execution is years away. The intelligence layer (knowing what to execute and why it's safe) remains the durable moat.
Research needed: licensing path for FX orchestration in UK/EU/US, "charge the banks" model viability (minimum customer base?), hedge accounting build vs. partner (Chatham?).
Competitive Landscape
| Segment | Players | What They Do | Palm's Angle |
|---|---|---|---|
| FX Execution Platforms | 360T (Deutsche Börse), FXall (Refinitiv/LSEG), Bloomberg FXGO | Multi-bank execution venues. Free to treasurers — charge banks for access. | Partners in Level 3, not competitors at Level 1-2. None have forecast-driven exposure intelligence. |
| FX Analytics & Automation | MillTechFX, Kantox (BNP Paribas), Bound, Pangea | Kantox: automated hedging workflows. MillTechFX: FX analytics (~$50K). Bound: SME-focused. | Closest competitors at Level 2. We don't understand MillTechFX well enough yet. Kantox is automation-first, not intelligence-first. |
| FX Risk in TMS | Kyriba, GTreasury, Chatham Financial | Modules inside TMS. Chatham is advisory/consulting. | Bolted-on modules, not core. Legacy infrastructure limits what they can do with AI. |
Key gap: No one owns the full flow from exposure identification through to settlement reconciliation on a normalised treasury data layer. But we need to validate this — we don't know enough about MillTechFX to be sure they don't cover Level 1-2.
Market Sizing
| Level | Size | Source | Confidence |
|---|---|---|---|
| TAM | ~$6.6B | Global corporate FX management software + transaction revenue | Vision Pillars — back-of-envelope |
| SAM | ~$800M–$1.2B | EU/US/UK large corporates (>$500M revenue) actively managing FX risk | Vision Pillars — back-of-envelope |
| Scenario A (Level 1-2) | $1M–$3.2M | SaaS intelligence layer — 25-40 enterprise customers | Vision Pillars — needs validation |
| Scenario A+B (Level 1-3) | $2M–$8M | Add orchestration fees, partner routing | Vision Pillars — speculative |
| Long-term (Year 7–9) | $63–140M | Full A+B across customer base | Vision Pillars — aspirational |
People pay ~$20-50K for FX analytics today — we could potentially push that to $40-80K given Palm's data advantage. But we'll only know when we try.
Knowledge Moat
What Palm accumulates over time that's hard to replicate:
- Entity-level currency exposure patterns — which entities are naturally long/short which currencies, and how that changes seasonally
- Customer-specific FX policies — hedge ratios, counterparty limits, tenor preferences, the informal "CFO doesn't like us being more than 20% exposed to EUR even though policy says 30%"
- Forecast-to-exposure correlation — how forecast accuracy in specific categories drives FX exposure uncertainty (this is unique to Palm — no FX tool has forecast data)
- Historical decision patterns — what the treasurer actually did in similar situations, building institutional memory
This is the "semantic layer" equivalent for FX. Competitors starting fresh would need months of per-customer configuration to replicate what Palm accumulates through normal usage.
Transcript Evidence (6+ sources)
**Sources:** - ON (2025-10-07): Currency dashboard feedback, exposure monitoring needs - ON (2026-02-18): Scenarios discussion including FX overlays - ON (2026-03-04): Scenario planning — FX scenarios explicitly requested - Personio (2024-11-26): Defined FX policy (3 months coverage), multi-currency needs - Levi's (2025-12-11): Acquisition FX planning, IC loan FX centralization - Treasury Dragons (2025-12-09): FX exposure monitoring as universal need - Instacart (2025-07-01): Multi-currency forecasting needs - Sonder (2024-11-19): Multi-currency forecasting - Volvo Cars (2025-03-27): FX impact on forecasts **Key quotes:** **Currency exposure monitoring:** > "Monitor currency exposures and cash pool positions...Minimize time required to identify currency shortfalls/surpluses" — ON **FX scenario modeling:** > "Once you see your scenario, it would be nice to see what you said was your best case, your baseline, and your worst case, and then with the actuals laid on top of that so it doesn't wipe out the history... similarly for fx, if it's called one way versus another way versus the point when you set your scenario." — ON (Jennifer) **Acquisition FX planning (6-8 months ahead):** > "An acquisition. Timing of when you close your acquisition. Could be also very influential if you have this data... most acquisitions. You know this. You're working in an acquisition, maybe six or eight months ahead of time. Then you can say, Let's just say also the acquisition is in foreign currency. Then you're able to then plan ahead." — Levi's (Dette) **FX centralization for IC loans:** > "Some companies will say, well, we want to centralize the FX exposure to the lending company. So the borrower should not be exposed. They borrow a million rupees, they pay back a million rupees. FX is with [the lender]." — Levi's (Dette) **FX policy exists, ready to encode:** > "We should...always keeping three months worth of foreign exchange in any currency" — Personio (Tom)Bet 2: Bridging & Working Capital Intelligence¶
Outcome: Explain to the CFO why actual cash differs from budget. Automate T+1 cash burn analysis. Progress to working capital intelligence — AR/AP movements, DSO/DPO, customer-level drill-down.
Target workflow: Month-end closes → treasurer opens Palm next morning → sees automated waterfall showing forecast vs. actual vs. budget → clicks into variance drivers (which categories, which entities) → exports CFO-ready report with explanations → feeds into board reporting.
Revenue¶
| Metric | Value | Source |
|---|---|---|
| Scenario A (Intelligence) | ~$500K–$1.5M (est.) | Product estimate — bridging as bundle component ($100K+ deals), working capital depth adds $50K+ standalone |
| Long-term potential | Higher with working capital depth | Could become standalone module if working capital intelligence is deep enough |
No direct Vision Pillars mapping — this is a product bet, not a company pillar. Revenue estimate is gut feel based on deal structure.
Note: Bridging alone is a bundle component (strengthens $100K+ deals), not a standalone module. Working capital intelligence — AR/AP movements, DSO/DPO tracking, customer-level drill-down — is where standalone revenue potential lives.
Competitive Landscape¶
| Segment | Players | Palm's Gap / Angle |
|---|---|---|
| Variance/Bridging | Kyriba (variance module), GTreasury, CashAnalytics | Basic variance exists in TMS. None connect forecast-driven variance with budget reconciliation automatically. |
| Working Capital Analytics | HighRadius, C2FO, Taulia, PwC/Deloitte advisory | Working capital optimization platforms exist but focus on supply chain finance, not treasury-integrated WC intelligence. |
| FP&A Tools | Anaplan, Adaptive Planning, OneStream | Own the budget side. Don't connect to treasury actuals. Integration opportunity. |
Key gap: No one automates the forecast → actual → budget reconciliation for treasury. FP&A tools own budgets, TMS tools own actuals, but the bridge between them is always a spreadsheet.
Trust Assessment¶
| Pillar | Rating | Rationale |
|---|---|---|
| Correctness | Medium | Bridging (forecast vs. actual) is deterministic — we have both datasets. Budget bridging needs budget data we don't currently ingest. |
| Structural safety | Low relevance | Analytical, not action-oriented. No execution risk. |
| Contextual alignment | High | Understanding why variance occurred requires institutional knowledge — "this entity always pays late in December," "that supplier changed payment terms." Palm accumulates this. |
Knowledge Moat¶
Palm accumulates: entity-specific variance patterns, seasonal cash flow drivers, customer payment behavior data, supplier payment term changes, explanations for historical variances (captured from treasurer corrections). Over time, Palm can pre-populate variance explanations — "collections were $2M below forecast, likely driven by Customer X's Q4 payment pattern (historically 15 days late in Dec)." This institutional memory is the moat.
Prioritization Assessment¶
- ACV Impact: Medium-High — Part of $100K+ bundle. Working capital depth could add $50K+ standalone. Pulls CFO into Palm (expands buyer beyond treasury).
- Evidence Strength: Strong — 4 deep sources with explicit bridging workflows (Personio, Euroports, Levi's, Instacart). 3 sources for working capital needs (ON, Levi's, Euroports).
- Path to Revenue: Expansion — Personio (T+1 pain, monthly process), ON (CFO reporting). New deals — US expansion angle (strong FP&A culture).
- Competition: Differentiated — No one automates the treasury ↔ FP&A bridge. Spreadsheets are the incumbent.
Practicality¶
| Dimension | Assessment |
|---|---|
| Customer to build with | Personio — T+1 analysis takes hours every month, entirely manual. Defined process to automate. |
| Data readiness | Medium — forecast vs. actual data exists in Palm. Budget data does NOT exist — need file upload first, then FP&A tool integrations (Anaplan, Adaptive Planning, OneStream, SAP BPC). |
| Timeline to skateboard | 6–8 weeks for bridging (forecast vs. actual). Budget integration adds 4–6 weeks. |
Effort Estimate¶
| Technical Layer | Status | Work Needed |
|---|---|---|
| Agent orchestration | Minimal | Bridging is deterministic calculation. Working capital analysis may benefit from agent-driven drill-down. |
| Context engineering | Partial | Forecast and actual data exists. Need: budget data ingestion pipeline, FP&A system integration specs. |
| Knowledge engineering | New build | Variance explanation requires: category-level pattern learning, entity payment behavior models, seasonal adjustment rules. This is the highest-value knowledge layer — the "why" behind every variance. |
Effort: Medium. Bridging baseline is straightforward. Working capital intelligence and budget integration add significant scope.
Risks¶
- Budget data ingestion is a real blocker — file upload is ugly, FP&A integrations are a significant build
- Working capital analytics is a crowded space (HighRadius, C2FO) even if the treasury angle is different
- Risk of being "good enough to demo, not good enough to replace Excel" if variance explanations aren't smart enough
Open Questions¶
- [ ] How to get budget data reliably (file upload → FP&A tool integrations: Anaplan, Adaptive Planning, Hyperion, BPC, etc.)
- [ ] How to get ERP data for AR/AP drill-down (Dynamics, NetSuite, SAP, Oracle)
- [ ] ACV validation — is bridging $50K standalone or only valuable as bundle component?
- [ ] US expansion angle — what % of US pipeline cares about bridging vs. other bets?
- [ ] Personio timeline — when do they want this? Can we build with them in Q2?
Transcript Evidence (5+ sources)
**Sources:** - Personio (2025-12-04): Direct/indirect bridging deep dive - Personio (2025-10-21): Reporting and forecast variance analysis - Euroports (2025-10-27): Bridging and variance explanation needs - Levi's (2025-12-11): Bridging, permanent vs timing differences, accountability - Instacart (2025-07-01): Forecast accuracy and variance needs - ON (2025-11-11): Variance analysis and ML trust **Key quotes:** **T+1 pain (Personio):** > "This is being developed... all of this analysis, anything like this stays outside the system. And it's always like the most painful... you have to take all the data out of the system, you have to generate a whole new spreadsheet." — Tom Thorn > "As soon as you shut that spreadsheet, it's out of date. It will never be looked at or used again." — Tom Thorn **Budget reconciliation (Personio):** Three types of variance analysis needed: 1. Actual vs Direct Forecast — treasury's transactional forecast 2. Actual vs Indirect Forecast — FP&A's budget 3. Forecast vs Forecast — treasury vs FP&A view **Bridging visualization (Euroports):** > "I really don't want to go back to Excel." — Euroports **Permanent vs timing differences (Levi's):** > "There's a different dimensions to it. One building trust. Having it been explainable, making sure it's transparent, making sure it's clear. What are the building blocks of this forecast?" — Dette **Working capital accountability:** > "That level of granularity...really helps you to feed back into the business and hold some of those teams accountable...if you can get that level of granularity then that's a huge [impact]" — Levi's (Dette)Bet 3: Tokenized Treasury & Cross-Border Payments¶
Outcome: Visibility into stablecoin-based settlement options for intercompany payments. Investment execution into yield-bearing tokenized products (e.g., BlackRock BUIDL). Faster IC settlements, reduced FX conversion costs, 24/7 settlement vs. banking hours.
Target workflow: Treasurer views upcoming IC payment → Palm shows cost comparison: SWIFT (2-3 days, 1.5% fees) vs. stablecoin rail (same-day, 0.1% fees) for this specific corridor → treasurer selects and initiates (Scenario B). At Scenario A: visibility and analytics only — "here's what you'd save."
Revenue¶
| Metric | Value | Source |
|---|---|---|
| Scenario A (Intelligence) | $600K–$2.8M | Vision Pillars — payment intelligence, routing optimization, stablecoin wallet visibility |
| Scenario A+B (+ Orchestration) | $3M–$12M | Vision Pillars — add payment initiation, on/off-ramp, corridor execution |
| Long-term (A+B, Year 7–9) | $50–200M | Vision Pillars |
| TAM | ~$4.2–$8.4B | Global cross-border payment technology revenue |
| SAM | ~$200–$500M | EU/US/UK large corporates willing to use stablecoin rails |
Market sizing from Vision Pillars doc. Stablecoin SAM is highly speculative — regulatory clarity pending.
Key nuance: Don't generalize this bet. Go corridor-specific. IC settlement via stablecoins (Klarna, PayPal precedent with fintech companies) is a more practical entry than broad cross-border. Separate the investment use case (tokenized funds like BUIDL — yield on idle cash) from the payment use case (faster IC settlement).
Competitive Landscape¶
| Segment | Players | Palm's Gap / Angle |
|---|---|---|
| Legacy Cross-Border | SWIFT GPI, Wise Business, Corpay (Fleetcor) | Established rails. Slow, expensive, but trusted by enterprise. |
| Blockchain-Native Settlement | Ripple / XRP, JPM Coin (Kinexys) | Bank-backed. JPM Kinexys handles $2B+/day but limited to JPM clients. |
| Stablecoin Infrastructure | Circle (USDC), Bridge (Stripe, $1.1B acquisition), BVNK, Conduit, Zero Hash | Built for fintechs and crypto-native. Enterprise treasury underserved. |
Key gap: Most stablecoin infrastructure targets fintechs. Enterprise treasury teams — Palm's ICP — are underserved. But enterprise adoption is unproven.
Trust Assessment¶
| Pillar | Rating | Rationale |
|---|---|---|
| Correctness | Low | Settlement amounts are deterministic, but real-time FX conversion rates, gas fees, and settlement timing introduce variability. New rails = new failure modes. |
| Structural safety | Uncertain | Regulatory uncertainty (MiCA live in EU, US legislation pending, UK FCA building regime). Enterprise treasury policies on crypto/stablecoin exposure undefined in most orgs. |
| Contextual alignment | Low | Zero customer evidence. No institutional knowledge to build on. We don't know how our ICP thinks about this. |
Knowledge Moat¶
Hypothetical: Palm could accumulate corridor-specific cost/speed data, settlement success rates, regulatory status tracking per jurisdiction, customer treasury policy encoding for digital asset exposure limits. But this knowledge layer doesn't exist yet because we have no customers in this space.
Prioritization Assessment¶
- ACV Impact: Unknown — Revenue projections ($600K–$2.8M at Scenario A) are entirely market-comp based. No customer validation.
- Evidence Strength: None — Zero customer mentions across all transcripts. No customer has expressed interest in tokenized treasury or stablecoin-based settlement.
- Path to Revenue: Speculative — No customer to build with today. Enterprise adoption examples limited to fintech companies (Klarna, PayPal).
- Competition: Unknown — Market is pre-competitive for enterprise treasury. Many well-funded players in adjacent spaces.
Practicality¶
| Dimension | Assessment |
|---|---|
| Customer to build with | None today. No customer has asked for this. |
| Data readiness | Low — would need entirely new data sources (blockchain settlement data, stablecoin wallet APIs, corridor-specific pricing feeds) |
| Regulatory readiness | Uncertain — MiCA (EU) is live but enterprise treasury adoption unclear. US and UK legislation pending. |
| Timeline to skateboard | TBD — can't estimate without clearer scope. Analytics-only (Scenario A) could be 8–12 weeks if scoped to 1-2 corridors. |
Effort Estimate¶
| Technical Layer | Status | Work Needed |
|---|---|---|
| Agent orchestration | New build | Payment routing optimization is genuinely agentic — multi-step comparison across corridors, real-time pricing, settlement tracking. |
| Context engineering | New build | Entirely new data sources. No existing Palm data to build on. |
| Knowledge engineering | New build | Regulatory status per corridor, settlement risk models, enterprise treasury policy encoding for digital assets. All greenfield. |
Effort: High. Every layer needs building from scratch. This is the highest-effort bet by far.
Risks¶
- Enterprise adoption may not materialize for 3-5 years — timing risk is the primary concern
- Regulatory landscape could shift unfavorably (e.g., US legislation stalls)
- Well-funded competitors (Circle, Stripe/Bridge) could move toward enterprise treasury faster than expected
- Reputational risk — being associated with "crypto" may alienate conservative treasury teams
Open Questions¶
- [ ] Which EU/US/UK corridors have regulatory clarity for enterprise stablecoin use?
- [ ] Who is actually doing IC settlement via stablecoins today? (Beyond Klarna/PayPal — are there non-fintech examples?)
- [ ] Attending upcoming stablecoin/payments conference session — capture enterprise sentiment
- [ ] Separate investment use case (BUIDL-type tokenized funds) from payment use case — which is more practical?
- [ ] What is Palm's actual risk appetite for operating in this space?
Transcript Evidence
No evidence found in current transcript base.
Searched for: stablecoin, blockchain, tokenized, USDC, crypto, cross-border payments (beyond standard international transfers)
Observation: This bet may be too early-stage for our current customer base. No customer has mentioned interest in tokenized treasury products, yield stablecoins, or blockchain-based settlement.
Action needed: Probe discovery calls explicitly to validate if this is a real need. Attend upcoming conference session on stablecoins/payments.
Bet 4: Deeper IC Intelligence¶
Outcome: IC loan tracking with interest accrual forecasting, in-house bank capabilities, forecast timing for periodic IC. Beyond current IC categorization work — move from "clean up IC data" to "manage the IC portfolio."
Target workflow: Treasurer opens IC dashboard → sees all active IC loans (borrower, lender, amount, rate, interest owed) → system forecasts quarterly interest settlement → flags loans approaching maturity → surfaces cost-plus AP-driven settlements that treasury didn't initiate → generates monthly IC report for accounting.
Revenue¶
| Metric | Value | Source |
|---|---|---|
| Scenario A (Intelligence) | ~$200K–$600K (est.) | Product estimate — $20–30K add-on per customer (gut), applicable to 10-20 customers with IC complexity |
| Long-term potential | Higher if IC loan tracking + in-house bank | Could connect to Pillar 3 (cross-border) long-term — IC settlement via stablecoins |
No direct Vision Pillars mapping — product bet. Revenue is add-on based on entity complexity. Could be higher if IC loan tracking proves widely needed.
Competitive Landscape¶
| Segment | Players | Palm's Gap / Angle |
|---|---|---|
| IC Modules in TMS | Kyriba IC module, ION IC, GTreasury | Kyriba IC module described as "complete mess" (Gurjit, Uber experience). Incumbents have modules but poor UX. |
| In-House Bank | SAP IHB, Reval/ION, FIS | Heavy, expensive, requires dedicated implementation. Not accessible to mid-market. |
| IC Reconciliation | BlackLine, Trintech | Focus on accounting reconciliation, not treasury intelligence. |
Key gap: No one provides IC intelligence — loan tracking with interest forecasting, funding suggestions, entity-level IC balance management — as a lightweight SaaS add-on. Incumbents require heavy implementation.
Trust Assessment¶
| Pillar | Rating | Rationale |
|---|---|---|
| Correctness | Medium | IC interest calculations are deterministic (rate × principal × time). But IC categorization accuracy is currently unsolved — miscategorized transactions propagate errors. |
| Structural safety | Medium | IC loans have compliance dimensions: thin capitalization rules, withholding tax, transfer pricing. System needs to encode these constraints. |
| Contextual alignment | High | Palm already knows entity structures, IC transaction patterns. Deep IC intelligence layers on existing knowledge — who lends to whom, at what rate, which pool. |
Knowledge Moat¶
Palm accumulates: entity-level IC relationship maps, cash pool netting logic, interest accrual calculation parameters, counterparty identification rules, AP-driven settlement patterns invisible to treasury. The "semantic layer" for IC: structured knowledge about how money moves between entities in this specific company. Competitors would need months of per-customer configuration to replicate.
Prioritization Assessment¶
- ACV Impact: Medium — $20–30K add-on (gut). Could be higher for complex organizations (50+ entities). Deepens existing account value.
- Evidence Strength: Strong — 5+ transcript sources. ON (daily IC interest accrual, multiple cash pools, ~800k discrepancies). Personio (forecast timing errors). Gurjit tracked 60+ IC loans at Uber. Kyriba IC module is a "complete mess."
- Path to Revenue: Expansion — ON (daily IC interest accrual, multiple cash pools), Personio (forecast timing fixes). Deepens existing accounts, not a new-logo driver.
- Competition: Differentiated — Lightweight SaaS IC intelligence vs. heavy TMS IC modules. Kyriba's failure is our opportunity.
Practicality¶
| Dimension | Assessment |
|---|---|
| Customer to build with | ON — daily IC interest accrual (1.25% rate), quarterly settlements, multiple cash pools (UBS, Deutsche Bank, JP Morgan). Also Personio for forecast timing. |
| Data readiness | Medium — IC transaction data exists in Palm. Need: interest rate parameters, loan terms, cash pool configuration. AP-driven IC settlements need ERP integration (Dynamics). |
| Timeline to skateboard | 8–12 weeks (product estimate, not eng-validated). IC loan tracking + basic interest forecasting. Full in-house bank is 6+ months. |
Effort Estimate¶
| Technical Layer | Status | Work Needed |
|---|---|---|
| Agent orchestration | Minimal | IC calculations are deterministic. Monthly report generation could be automated. |
| Context engineering | Partial | Entity structure and IC transactions exist. Need: loan terms, interest rates, cash pool configuration, ERP-sourced AP settlement data. |
| Knowledge engineering | Significant | Need: thin capitalization rules per jurisdiction, withholding tax calculations, benchmark rate integration (avoid manual Bloomberg updates), IC counterparty identification rules, netting logic. |
Effort: Medium. IC loan tracking is achievable. Full in-house bank capabilities (COBO/POBO) are a much larger build — defer unless commercially validated.
Risks¶
- IC categorization accuracy is a prerequisite — if current categorization is unreliable, IC intelligence compounds the errors
- COBO/POBO workflows have no transcript evidence — validate before building
- Commercial signal is unclear — do prospects with 50+ entities actually pay $20-30K+ for IC intelligence?
- Thin capitalization and transfer pricing compliance could pull us into tax advisory territory
Open Questions¶
- [ ] How many prospects have 50+ entities? (Pipeline data needed — qualify IC complexity)
- [ ] Commercial signal beyond current customers — is there ACV potential beyond categorization fixes?
- [ ] COBO/POBO workflows — validate with customers or remove from scope
- [ ] Build effort for IC loan tracking vs. full in-house bank capabilities — where's the value/effort boundary?
- [ ] ERP integration for AP-driven settlements — how hard is Dynamics API integration?
Transcript Evidence (5+ sources)
**Sources:** - ON (2026-02-02): IC sync — interest accrual, cash pool tracking - Personio (2026-02-02): IC sync — ZBA balance display blocker, forecast timing issues - Internal (2025-12-02): Gurjit's IC loan workbook walkthrough (Uber — 60+ loans tracked manually) - ON (2026-02-18): IC in scenarios discussion - ON (2025-11-17): Kyriba walkthrough and IC issues - ON (2025-10-07): IC categorization problems **Key quotes:** **IC interest accrual tracking (ON):** > "Tracks IC loans actively with daily interest accrual (1.25% between On Holding and On AG)" — ON IC sync > "Interest forecasting: extrapolate accrued interest into next two months" — ON IC sync **Multiple cash pools (ON):** > "Multiple IC positions across cash pools (UBS, Deutsche Bank, JP Morgan)" — ON IC sync > "~800k discrepancy in JP Morgan pool due to categorization issues" — ON IC sync **Forecast timing errors (Personio):** > "They have very specific once a month transfers, which should be quite easy to forecast. But the forecasts are not being pinned to the correct week. They're just being attributed over the year." — Personio IC sync **Kyriba IC module failure (Uber):** > "We try to take this and put it into Kyriba. We did go through an RFP with Kyriba to get their intercompany loan module. It was a complete mess." — Gurjit **IC loan tracking needs (Uber):** > "borrower, lender, amount, interest rate, how much is borrowed, how much interest is owed, how much interest is paid — great report...because most treasury teams are building these and sending these out on a daily basis." — Gurjit **AP-driven settlements invisible to treasury:** > "Large amounts ($5-20M/month), kicked off by AP not treasury, flow from one entity to many" — IC sync (2026-02-02) **Complex withholding tax tracking (Uber):** > "We need to calculate what the withholding tax is between and between the two countries" — GurjitBet 5: Direct Bank Connectivity¶
Outcome: Own the connection layer instead of sitting on top of Kyriba/TMS. Control full data pipeline (quality, freshness, semantics). Extend beyond banks to investment platforms, FX brokers, tokenized treasury providers.
Target workflow: Not a distinct end-user workflow — this is infrastructure. Customer connects Palm directly to bank APIs → Palm normalizes data → higher data quality, fresher balances, richer transaction detail → enables better forecasts, faster variance detection, real-time positioning.
Revenue¶
| Metric | Value | Source |
|---|---|---|
| Scenario A (Intelligence) | Enabler — no direct revenue | Connectivity enables higher ACVs but is not independently priced |
| Strategic value | Prerequisite for execution bets | Owning connectivity is required for Scenario B/C in FX, investments, and payments |
This is not a revenue bet. It's a strategic enabler. Revenue comes from the bets it enables.
Competitive Landscape¶
| Segment | Players | Palm's Gap / Angle |
|---|---|---|
| Banking Connectivity Aggregators | Fides, Cobase, TIS | Middle-ground option — partner rather than build. |
| TMS Connectivity | Kyriba, ION, GTreasury | Incumbents own bank connectivity as core feature. Decades of bank integrations. |
| Open Banking / APIs | Plaid (consumer), Yapily, TrueLayer | Consumer-focused. Enterprise treasury APIs are different (SWIFT, host-to-host, EBICS). |
Key consideration: Agent orchestration may commoditize connectivity. OpenAI Frontier-type agents that coordinate across bank portals and TMS platforms could make "owning the pipes" less valuable. But most legacy platforms don't even have public APIs yet — agent-based connectivity is years away for enterprise banking.
Trust Assessment¶
| Pillar | Rating | Rationale |
|---|---|---|
| Correctness | N/A | Connectivity is plumbing, not intelligence. Data quality improves with direct connection. |
| Structural safety | N/A | Execution-layer concern. Not relevant at Scenario A. |
| Contextual alignment | N/A | Connectivity doesn't require institutional knowledge. |
Trust assessment not applicable — this is infrastructure, not an intelligence bet.
Knowledge Moat¶
Limited. Bank connectivity is commoditizable. The moat is in what you do with the data, not in how you get it. Palm's moat is the intelligence layer — connectivity is a means to an end.
Prioritization Assessment¶
- ACV Impact: Indirect — Enables higher ACVs but not independently priced. Some prospects (Euroports, Personio, Dunelm, Discogs) lack reliable connectivity and might pay for it.
- Evidence Strength: Moderate — 3+ transcripts with integration blockers and data quality issues. Not a customer-requested feature — more an observed pain.
- Path to Revenue: Strategic — Prerequisite for execution scenarios (B/C). Not a near-term revenue driver.
- Competition: Parity — TMS incumbents have decades of bank integrations. We'd be catching up, not differentiating.
Practicality¶
| Dimension | Assessment |
|---|---|
| Customer to build with | Various — Euroports, Personio lack reliable connectivity. ON has Dynamics API readiness. But ICP mostly has connectivity via existing TMS. |
| Data readiness | N/A — this IS the data readiness bet. |
| Urgency | Low near-term — ICP mostly has connectivity. Becomes important if/when we pursue execution (Scenario B/C). |
Effort Estimate¶
| Technical Layer | Status | Work Needed |
|---|---|---|
| Agent orchestration | N/A | Not an agent problem. |
| Context engineering | N/A | Not a context problem. |
| Knowledge engineering | N/A | Not a knowledge problem. |
| Pure engineering | High | Bank API integrations (SWIFT, host-to-host, EBICS), data normalization, error handling, reconciliation. Significant build. Could partner (Fides) to reduce. |
Effort: High if building. Lower if partnering with connectivity aggregator (Fides, Cobase). Build vs. partner decision is key.
Risks¶
- Massive build effort for diminishing returns near-term (ICP mostly has connectivity)
- Agent-based orchestration could commoditize connectivity in 3-5 years
- Distracts from intelligence bets that drive immediate revenue
- Bank integration maintenance burden is ongoing (APIs change, formats evolve)
Open Questions¶
- [ ] Does owning connectivity justify higher ACVs? (Need sales validation)
- [ ] Build vs. partner decision — evaluate Fides as middle-ground option
- [ ] Which customers would actually pay for direct connectivity vs. TMS integration?
- [ ] When does agent-based orchestration make direct connectivity less valuable?
Transcript Evidence (3 sources)
**Sources:** - ON (2026-02-18): Dynamics API integration readiness discussion - ON (2025-11-17): Kyriba walkthrough revealing limitations - Internal (2025-12-02): IC loan workbook and data pipeline challenges **Key quotes:** **Dynamics API integration readiness:** > "We have a new IT product manager for Dynamics who is excited about the integration. Ready to kick off, may get resources in Q2. Wants specs/documentation from Palm." — ON **Kyriba limitations in forecasting:** > "What Kyriba does is grabbing our initial balance, adding all of the expected outflows, expected inflows. Nothing super smart, nothing of AI, no nothing fancy." — ON **HighRadius integration data flow:** > "There is no connection for all of the enhanced data or insights from high radius flowing to Dynamics or to the data lake. It stays within high radius." — ON5. Stack Rank¶
Comparison Table¶
| Rank | Bet | Scenario A Revenue | Evidence | Trust Readiness | Effort to Skateboard | Customer to Build With | Strategic Value |
|---|---|---|---|---|---|---|---|
| 1 | FX Risk Intelligence | $1M–$3.2M | Strong (6+ sources) | High — deterministic calcs, data exists | Low (4–6w) | ON (active) | Highest ACV uplift. Equity story. |
| 2 | Bridging & Working Capital | ~$500K–$1.5M | Strong (4 deep) | Medium — needs budget data | Medium (6–8w) | Personio | CFO buyer. US expansion. |
| 3 | Deeper IC Intelligence | ~$200K–$600K | Strong (5+) | Medium — categorization unsolved | Medium (8–12w) | ON | Deepens existing accounts. |
| 4 | Tokenized Treasury | $600K–$2.8M | None (0 sources) | Low — regulatory uncertainty | High (TBD) | None today | Massive long-term, timing risk. |
| 5 | Direct Bank Connectivity | Enabler (no direct) | Moderate (3) | N/A — infrastructure | High | Various | Strategic prerequisite. |
Ranking Rationale¶
#1 FX Risk Intelligence — Strongest on every dimension except one (hasn't been tested commercially). Highest revenue potential at Scenario A. Strongest evidence base. Lowest effort — mostly new views on data we already have. ON is ready to co-develop. Biggest equity story impact. This is the clear top bet.
#2 Bridging & Working Capital — Strong evidence, medium effort, and a unique strategic angle: it pulls the CFO into Palm (expands the buyer). US expansion angle is real (FP&A culture). The budget data dependency is the main risk — file upload can get us started, but long-term needs FP&A integrations.
#3 Deeper IC Intelligence — Strong evidence from existing customers (ON, Personio), proven competitor failure (Kyriba IC module), and layers on existing data. Ranked below bridging because: narrower addressable market (only relevant to complex multi-entity orgs), lower standalone ACV, and IC categorization accuracy is a prerequisite we haven't fully solved.
#4 Tokenized Treasury — Large Vision Pillars revenue number ($600K–$2.8M) but zero customer evidence. The revenue projection is entirely market-comp based. Enterprise adoption is unproven, regulatory landscape is shifting, and we'd be building every technical layer from scratch. High optionality value — but not a near-term bet.
#5 Direct Bank Connectivity — Strategic enabler, not a revenue bet. ICP mostly has connectivity today. Becomes important if/when we pursue execution (Scenario B/C), but investing here now means less capacity for intelligence bets that drive immediate revenue. Consider partnering (Fides) rather than building.
6. Recommended Sequencing¶
Start Now¶
| Bet | Action | Timeline |
|---|---|---|
| FX Risk Intelligence | Begin skateboard with ON. Exposure visibility → FX scenarios → decision intelligence. | Q2 2026 kickoff, skateboard by end Q2 |
Continue / Prepare¶
| Bet | Action | Timeline |
|---|---|---|
| Bridging | Scope with Personio. Design budget data ingestion (file upload MVP). | Q2 2026 scoping, Q3 build |
| IC Intelligence | Fix IC categorization accuracy first (prerequisite). Then scope IC loan tracking with ON. | Q2-Q3 2026 |
Watch¶
| Bet | Action | Timeline |
|---|---|---|
| Tokenized Treasury | Attend upcoming conference session. Probe discovery calls. Revisit in 6 months. | Q4 2026 re-evaluation |
| Direct Connectivity | Evaluate Fides partnership. Don't build unless execution bets (Scenario B/C) are greenlit. | 2027+ |
7. Research Gaps¶
These are the things Emma needs to go deeper on before the next management session:
FX Deep Dive (Priority — supports #1 bet)¶
- [ ] Understand MillTechFX business model and product offering — what does $50K FX analytics actually deliver?
- [ ] Kantox pricing and positioning — are they moving toward analytics or staying execution-focused?
- [ ] Bound's approach — simpler competitor targeting SME, but could they move upmarket?
ACV Validation (Critical — all pricing is gut feel)¶
- [ ] All pricing estimates need validation against actual deal data (Christian/Gurjit to pull sales input)
- [ ] What % of current pipeline is multi-currency? (FX bet addressable market)
- [ ] How many prospects have 50+ entities? (IC bet addressable market)
- [ ] Is bridging priced as standalone or only bundle component?
Effort Validation (Required before committing)¶
- [ ] All build estimates need engineering review — product estimates only, not validated
- [ ] FX skateboard: can we really ship exposure views + FX scenarios in 4–6 weeks?
- [ ] Bridging: what's the real effort for budget data ingestion (file upload MVP)?
ON Case Study (Specific management request)¶
- [ ] Model ON's contract value across FX + investments + payments at Scenario A
- [ ] This was requested directly — needs to be ready for next session
Stablecoin / Payments Research¶
- [ ] Which EU/US/UK corridors have regulatory clarity for enterprise use?
- [ ] Enterprise adoption examples beyond fintech companies (Klarna, PayPal)
- [ ] Attend upcoming conference session — capture sentiment and use cases
Outcome-Based Pricing (Exploratory)¶
- [ ] Research pricing models beyond module pricing — can we price on outcomes (savings, efficiency)?
- [ ] How do competitors price FX analytics? (Per user, per entity, % of notional, flat fee?)
Knowledge Layer Per Bet (Thesis application)¶
- [ ] For each bet, map what structured knowledge Palm needs to accumulate — similar to how the thesis's semantic layer drove text-to-SQL from 16.7% → 83%
- [ ] What's the "semantic layer" equivalent for FX? For bridging? For IC?
- [ ] Where does institutional knowledge become the binding constraint vs. just needing better data?
Last updated: 2026-03-11