Optima — Product Requirements v1.1

Version: 1.1 · 2 November 2026 · Product owner: Pia

Status: Product baseline documented; not yet Ready for implementation. Consolidates the channel's decisions through approved mockups v0.16. Real-alert tests, exact pilot card rules, missing error-state mockups and CTO effort/cost/risk review remain open. Supersedes PRD v1.0; the earlier version remains available.

Mockup baseline: https://optima-mockup.pages.dev/ · Design system: https://optima-mockup.pages.dev/design-system.html

Changelog

v1.1: Researched Singapore reward mechanics on 2 November 2026. Adds the reward-rule coverage appendix, distinct minimum/cap labels, multiple allowances on Home, transaction blocks and rounding, purchase-count and multi-period conditions, reward units, partial-cap explanations and test cases. Extends F-05–F-10 without adding a new feature ID. Mockups remain v0.16; new rule states are not yet drawn. This is a product requirement update, not a claim of verified support for every card.

v1.0: First consolidated PRD. Includes Optima naming, blue/white design, DM Sans only, Google sign-in, forwarded alerts, exact-product reward rules, remaining allowance, estimated cashback and miles, category tags, MCC labels, monthly/cycle history with eligible percentages, card images, and review pop-ups. Mockup v0.16 is a separate design version, not PRD v0.16.

Problem

A Singapore cardholder managing multiple personal credit cards needs to see which card has remaining bonus capacity before spending. Each card can have different categories, minimum tiers, caps and reward periods. Captured bank alerts bring purchases into one view and make missed bonuses visible.

Fact — product decisions: One person, multiple personal credit cards; both calendar-month and statement-cycle spending. Planned banks: DBS/POSB, UOB, OCBC, Citi, HSBC and Maybank. This is planned coverage, not verified support for every product.

Assumption: Forwarded alerts provide enough useful coverage for a pilot. To validate: what each bank actually sends, including recurring payments, instalments, refunds and foreign-currency purchases. All spending and reward amounts remain estimates from captured alerts, not statement balances or bank-confirmed payouts.

Options

Goals and measures

These are proposed pilot acceptance targets, not measured results. No reward-uplift claim is established.

Cashback and miles stay separate. Do not sum them into one reward total without an explicit valuation choice.

Users

Primary persona (assumption): A Singapore resident with two or more personal credit cards who knows rewards exist but cannot remember every category and limit. They check their phone before spending and revisit previous months.

Secondary situation: The same person resolving a missing alert, wrong card assignment or missed bonus. Household sharing and business accounting are not Phase 1.

Journeys

• J1 — Set up: Google sign-in → exact card products, last four digits and statement dates → forwarding instructions → test alert → captured purchase. Cancelled sign-in, unsupported products and failed tests retain completed setup and offer a clear retry.
• J2 — Decide before spending: Home monthly total → compare remaining allowance per card → open details to see categories, relevant reward period and estimated earned rewards. Unknown rules or merchant codes suppress definitive advice.
• J3 — Review: Tap a transaction or Home review count → pop-up explanation → correct category/card or keep excluded → return to the same context. Cancelling changes nothing; saving errors preserve the user's entries.
• J4 — Look back: History from Home/card → month or card cycle → chart and eligible percentage → actual period transactions. No captured data is not presented as zero bank spending.

Phase 1 requirements

P0 means required for the fixed Phase 1 scope. The criteria below describe the working product; static mockups do not prove implementation.

F-01 · P0 · Sign-in and private access

Story: As a cardholder, I can sign in before seeing spending or my forwarding setup.

• F-01.AC1: Given I am signed out, when I open spending, history or forwarding setup, then sign-in is required before private content appears.
• F-01.AC2: Given Google sign-in, when it succeeds, then I resume setup or my Home; failure/cancellation offers retry and preserves completed setup.
• F-01.AC3: Given two accounts, when either attempts to access the other's content, then no private content is revealed. Signing out prevents further private access.

Mockup: Sign-in.

F-02 · P0 · Card identity

Story: As a cardholder, I recognise each exact card by image, product and last four digits.

• F-02.AC1: Given a supported card, when added, then bank, exact product, last four digits, statement day and reward type are recorded; ambiguous product choices require clarification.
• F-02.AC2: Given a card page or list, when shown, then its visible wrapper groups identity with the card image. Missing artwork uses a plain card in the chosen colour with readable identity text.
• F-02.AC3: Given a personal credit limit is displayed, when compared with rewards, then it is labelled separately and never used as a reward cap. Unavailable reward rules are not replaced with another card's terms.

Mockups: Connect, Cashback card, Miles card.

F-03 · P0 · Forwarded alerts

Story: As a cardholder, I can forward transaction alerts and check that setup works.

• F-03.AC1: Given I am signed in, when setup opens, then I see my distinct tagged forwarding destination, alert prerequisites, forwarding instructions and a test step.
• F-03.AC2: Given an agreed supported alert, when received, then card, merchant, amount, currency and available transaction time appear once. Forwarding the same alert twice creates no duplicate purchase.
• F-03.AC3: Given account, card, amount or currency is ambiguous, when an alert arrives, then it is held for review and excluded from affected totals until resolved; never guess another person's account.
• F-03.AC4: Given no test alert arrives or recognition fails, when setup is revisited, then its actual state and retry guidance are visible. Test success confirms capture, not complete bank coverage.

Mockups: Forwarding, Test.

F-04 · P0 · Period totals and credits

Story: As a cardholder, I can see calendar-month and per-card statement-cycle spending and correct missing refunds.

• F-04.AC1: Given dated captured purchases, when a month or cycle is chosen, then the displayed dates govern totals and transaction lists. Calendar months use Singapore time; purchases count once in each applicable view.
• F-04.AC2: Given different statement dates, when viewing cycles, then one card is selected at a time with its own boundaries, including short months where the selected day does not exist.
• F-04.AC3: Given a captured refund or confirmed manual correction, when recorded, then it credits net spending once; reward adjustments follow the verified product rule. Missing refunds are not assumed.
• F-04.AC4: Given an unreliable Singapore-dollar conversion, when totals appear, then the original amount and unresolved conversion remain visible; no invented exchange rate or final charge is used.

Mockups: Home, Card, Cycles. Additional refund/conversion states required before Ready.

F-05 · P0 · Exact reward rules

Story: As a cardholder, I track the relevant spending threshold and cap for my actual card product.

• F-05.AC1: Given a supported product, when rewards open, then reward type, qualifying spend, tiers, category rules, exclusions, caps and reward period are identified, with official source and effective date available.
• F-05.AC2: Given known eligibility, when calculating progress, then eligible spend advances the applicable bonus cap and non-eligible spend stays separate. Minimum-tier qualifying spend follows its own terms; it is not automatically identical to bonus-category spend.
• F-05.AC3: Given multiple categories or caps, when viewed, then multiple category tags and the applicable separate limits appear. A shared cap is used only where the card terms specify one.
• F-05.AC4: Given estimated cashback or miles, when displayed, then they are labelled estimated and separate from spend progress. A personal miles goal never substitutes for a spending threshold. Missing rules yield an unclear or unavailable estimate.
• F-05.AC5: Given a changed rule, when history is opened, then the dated rule applicable to that period is used; current rules must not silently rewrite the past.

Mockups: Rewards, Cashback, Miles.

F-06 · P0 · Compact Home and allowance left

Story: As a cardholder about to spend, I can compare remaining allowance quickly.

• F-06.AC1: Given captured spending, when Home opens, then its top shows all-card monthly spend, eligible/not-eligible/to-check split, separate estimated cashback/miles, review count and History link.
• F-06.AC2: Given a verified card rule, when its compact row appears, then remaining spending to the labelled next tier or cap is prominent, with spent, bonus spend and estimated earned underneath. If more than one independent allowance applies, show compact labelled allowances rather than one pooled number; expand to all conditions on the card page. The applicable period is clear even if it differs from the calendar month.
• F-06.AC3: Given a bonus cap is reached/exceeded, when remaining allowance is zero/negative, then the number is red and labelled cap reached/over cap. Overages remain visible. Minimum-tier completion stays blue and is a success rather than wasted spending.
• F-06.AC4: Given unresolved spending or rules, when allowance is shown, then it says uncertain/unavailable rather than a misleading zero. Detailed progress and the full category list stay on the card page; the category names needed to distinguish independent Home allowances remain visible.

Mockups: Home, Zero/negative examples.

F-07 · P0 · Transactions and merchant category codes

Story: As a cardholder, I can trace totals to transactions and understand bonus eligibility.

• F-07.AC1: Given a card or past period, when transactions are listed, then every captured purchase is reachable below the summary with merchant, date, amount, card and bonus status; long lists do not silently omit older items.
• F-07.AC2: Given any transaction row, when displayed, then it includes its merchant category code (MCC) or MCC unknown. A supplied code and an inferred match have distinct provenance; inferred codes are never called bank-confirmed.
• F-07.AC3: Given unresolved eligibility, when shown, then it says Reward unclear rather than known non-eligible. Changing a readable category does not establish the bank's MCC or bonus entitlement.
• F-07.AC4: Given colour is unavailable, when reading status or charts, then text still distinguishes blue eligible, amber missed bonus and grey to-check spending.

Mockups: Card transactions, Miles transactions, Past month.

F-08 · P0 · Review in pop-ups

Story: As a cardholder, I can review and correct a purchase without leaving my place.

• F-08.AC1: Given any purchase row, when tapped, then its pop-up shows amount, card, MCC/provenance, category, month, cycle and reward explanation, with Change category and Not this card actions. No dedicated Review page/tab is required.
• F-08.AC2: Given unresolved purchases on Home, when the count is tapped, then a pop-up list opens and each item opens its review sheet over Home.
• F-08.AC3: Given a valid correction, when saving succeeds, then the purchase, affected totals and review count update together and the user returns to the same context. Cancel changes nothing; save failure preserves entries and offers retry.
• F-08.AC4: Given an ambiguous purchase, when Keep excluded is chosen, then it remains excluded from affected calculations with a visible reason. Correcting category alone does not confirm an unknown MCC.
• F-08.AC5: Given the pop-up opens, when using keyboard/assistive navigation, then the title is announced, focus stays inside, close is reachable and closing restores focus to the trigger.

Mockups: Purchase sheet, Unclear purchase, Home review list.

F-09 · P0 · Monthly and cycle history

Story: As a cardholder, I can inspect past spending and its bonus eligibility.

• F-09.AC1: Given captured past data, when History opens, then Monthly is selected with a six-period stacked spend chart, percentage under each bar and matching period rows. Earlier available periods remain reachable.
• F-09.AC2: Given card/month/cycle filters, when changed, then chart, percentages, totals and rows use the same selection. A card's history links open that card's history; cycles show one card at a time.
• F-09.AC3: Given a period bar/row is tapped, when opened, then its actual totals, per-card final progress and transactions appear. Previous/next must change the period rather than repeat the October mockup.
• F-09.AC4: Given incomplete current capture, when shown, then say so far. A period with no data says no captured data. Unresolved eligibility remains visible in past periods rather than disappearing at month end.
• F-09.AC5: Given a correction or late alert affects history, when confirmed, then affected estimates update and indicate revision; history is not an immutable bank-statement snapshot.

Mockups: All months, Card months, Cycles, Period.

F-10 · P0 · Eligible percentage

Story: As a cardholder, I can compare eligible share without confusing unknown spending with success.

• F-10.AC1: Given positive captured purchases, when eligible percentage appears, then it is the portion of purchases covered by the applicable bonus divided by all captured purchase amounts in the period, including unclear eligibility, multiplied by 100 and rounded to a whole percent. Label this Bonus-covered share of captured purchases. In v1.1, split purchases crossing a cap; exclude portions that earn only base rewards, are excluded, or receive no reward because of transaction-block rounding. Do not add the same covered portion twice when bonuses overlap. Conditions not yet satisfied remain conditional, outside the covered numerator, and visible in the to-check amount. This is a reporting measure, separate from minimum-spend qualification.
• F-10.AC2: Given refunds/credits, when computing that percentage, then they are not treated as new purchases or allowed to create a negative denominator; display credits and net spend separately. This is a new v1.0 reporting convention, not an issuer reward calculation.
• F-10.AC3: Given no captured purchases, when percentage is shown, then use an em dash with No captured purchases, not 0%/100%. Disclose unresolved share when eligibility is unknown.
• F-10.AC4: Given cycle history, when rewards are displayed, then monthly cashback/miles are not assigned to a cycle without a verified matching reward period. Spend and reward units never share a misleading chart scale.

Mockups: Months, Cycles. Refund/empty/uncertain-history examples still required before Ready.

F-11 · P0 · Priority and reward flags

Story: As a cardholder, I can set a preference and understand when another owned card may be better.

• F-11.AC1: Given owned cards, when I reorder priority in Settings, then it is saved and breaks ties between comparable eligible choices.
• F-11.AC2: Given a known missed bonus, when flagged, then its explanation identifies the exclusion/exhausted cap. Any suggested card must be owned, have a verified relevant rule, known eligibility and remaining allowance.
• F-11.AC3: Given unknown MCC, missing rules or incomparable cashback/miles without a valuation, when advice is shown, then there is no definitive best-card claim; show uncertainty and relevant options.

Mockups: Settings, Rewards.

F-12 · P0 · Phone experience and honest estimates

Story: As a cardholder, I can scan Optima on my phone and understand its limitations.

• F-12.AC1: Given any app screen, when displayed at 360-pixel phone width, then it fits without sideways scrolling, uses DM Sans only and follows the approved blue/white system. Essential actions have touch targets at least 44 pixels.
• F-12.AC2: Given main navigation, when moving between screens, then its tabs are Home, Cards, Rewards and Settings. History is available from Home/card details; Review opens in a pop-up.
• F-12.AC3: Given spending, allowance or rewards, when shown, then estimate/incomplete-capture wording is accessible without long repeated explanations; figures do not imply a bank-confirmed payout or balance.
• F-12.AC4: Given setup, when requesting card details, then ask only for needed information and never request bank passwords, full card numbers or security codes for this forwarding workflow.

Mockups: Design system, Home.

Additional v1.1 acceptance criteria for existing P0 features

All examples below are invented test fixtures unless explicitly tied to a cited issuer. No new feature IDs are introduced; previous IDs retain their identity.

• F-05.AC6: Given a fixture with S$1,000 maximum bonus spend, S$793 already consuming that cap and a stated 10 miles/S$1 rate, when progress opens, then it shows S$207 bonus spend left, the rate and reset period. It never calls this a minimum spend. The fixture does not claim that any researched bank offers that rate.
• F-05.AC7: Given a separate S$1,000 minimum with S$793 qualifying spend, when progress opens, then it shows S$207 to unlock, the unmet conditions and deadline. Reaching it changes the label to Minimum met; it does not say Cap reached. If both minimum and cap apply, show both.
• F-05.AC8: Given independent S$600 online and S$600 mobile limits with S$600 online and S$200 mobile used, when viewed, then online shows S$0 and mobile S$400; unused online capacity cannot move to mobile. Given a separate S$300 overall limit remaining, then the displayed mobile usable amount is at most S$300, with both constraints explained.
• F-05.AC9: Given a whole-S$5-block-per-purchase fixture, when S$14.99 is captured, then spend remains S$14.99, reward-bearing spend is S$10 and the S$4.99 remainder is explained. Two S$2.50 purchases produce no blocks; one S$5 purchase produces one. Never combine separate purchases unless that exact rule permits aggregation.
• F-05.AC10: Given different rounding fixtures, when calculating, then a whole-S$5-block rule applied to S$14.99 at 10 points per block yields 20 points; a points-rounded-at-end rule at the same nominal rate yields 29 points. Given a monthly whole-dollar-aggregation fixture, two S$2.60 purchases yield S$5 reward-bearing spend; a per-purchase whole-dollar rule yields S$4. Use the verified sequence, not a bank-wide rounding default.
• F-05.AC11: Given a fixture requiring S$600 and 10 purchases in each of three statement periods, when one period has S$650 and 9 purchases, then that period fails the count condition and the quarterly benefit remains unqualified. Surplus spend/count in another period does not repair it. Show each period and both conditions.
• F-05.AC12: Given a points cap, when remaining capacity is shown, then retain its native unit. For a fixture with 900 bonus points left at 9 bonus points/S$1, show S$100 equivalent only if rounding, rate and other conditions permit that conversion. Never label 10X points as 10 miles/S$1; miles equivalence identifies the chosen conversion programme and excludes transfer fees from earned rewards.
• F-05.AC13: Given an eligible purchase crossing a cap, when calculated, then show the covered and excess portions, base and bonus estimates, and the reason. At S$20 remaining under a simple unrounded spend-cap fixture, a S$50 purchase covers S$20 at the bonus rate and S$30 at the verified fallback rate; zero fallback must be explicit. If block allocation or transaction ordering is unresolved, mark the estimate uncertain instead of assuming this split.
• F-05.AC14: Given a user-selected category, registration, qualifying payment method or external account condition, when the needed fact is missing, then the bonus remains conditional. A category correction cannot prove mobile-wallet use, registration or a deposit balance. Collect only the necessary confirmation and label its source; no bank login is requested.
• F-05.AC15: Given purchase date 31 October and issuer posting date 2 November under a posting-date rule, when computing reward capacity, then it belongs to November while the purchase-date spending history remains October. If posting date is unavailable, period allocation is provisional. Late refunds follow the verified reversal rule and do not automatically reopen current capacity.
• F-05.AC16: Given several reward components or a dated promotion, when estimating, then apply each component's dates, eligibility, cap and stacking rule once. Expired or unregistered promotions do not inflate standing rewards. Unsupported stacking rules remain unavailable.
• F-06.AC5: Given several active constraints, when Home appears, then label each visible amount by purpose and category, show the reward-period reset date and mark unmet gates. Red on an exhausted category does not imply all categories on the card are exhausted; no universal Switch cards claim is made if other rewards remain.
• F-07.AC5: Given a purchase affected by a cap, block, exclusion or unmet condition, when its pop-up opens, then show original spend, the part used for threshold/cap progress, reward-bearing amount, base/bonus estimates and the reason for the difference. A zero-points rounding case is distinguished from an excluded merchant.
• F-08.AC6: Given a known purchase amount/card but uncertain reward facts, when reviewed, then it remains in captured spending while only eligibility/cap estimates are uncertain. Ambiguity about the amount, currency or card still excludes the affected spending totals under F-03.AC3. Keep excluded identifies which calculation it excludes.
• F-09.AC6: Given a late alert, correction or dated rule change, when a past estimate changes, then retain the original captured facts, the correction, the applied rule/source date and an explanation of the revision. Estimated earned, conditional and bank-confirmed credited rewards must not be conflated; without bank evidence Optima shows estimates only.
• F-10.AC5: Given one S$50 purchase with S$20 bonus-covered and S$30 base-only, when its period contains no other purchases, then the bonus-covered share is 40%, not 100%. Given only one S$14.99 purchase with S$10 bonus-covered under a S$5 block fixture, then it is 67% after rounding. The legend includes base-only/excluded/rounding in the amber amount and uncertain/conditional portions in grey, with reason details available.

Later priorities

P1: Expand exact-card coverage after validation; richer comparisons with explicit user valuation for cashback versus miles; additional forwarding-provider guidance after real tests. This extends rather than replaces the P0 conditional flags.

P2: Advanced purchase planning and trend analysis. Proactive warnings remain undecided: the previously proposed 80% warning and 10-per-day notification limit are not accepted requirements.

Phases and readiness

Phase 0 — Validation: Obtain redacted alerts, exact pilot card products and dated terms; test forwarding and MCC availability; resolve reward-period, refund and conversion cases; obtain CTO effort, cost and risk for each P0. No schedule or budget is committed.

Phase 1 — Fixed product scope: F-01–F-12, including history and pop-up reviews. The initial supported product list must be explicit before release; Appendix A defines the standing-rule coverage required for each supported product. The six-bank plan is not permission to claim untested support. Do not silently shrink scope or substitute bank-wide rules.

Phase 2: P1 work after Phase 1 acceptance and a versioned scope decision. P2 is outside this commitment.

Ready gate: Every P0 has testable criteria and approved mockups for normal and material failure states, no blocking open issue, verified supported products and dated rules, and CTO effort/cost/risk review. Current status is not Ready.

Mockup baseline and gaps

Approved baseline: Optima v0.16, original blue design and DM Sans. Every amount, card image, merchant code and rule shown is illustrative. Earlier visual studies are rejected alternatives.

• Sign-in, saving, forwarding and corrections are demonstrations, not working functionality.
• Past-period links currently share an October example; the product must open each actual period.
• Historical uncertainty must remain visible even when a period closes.
• Official artwork needs usage checks; a plain-card fallback is required.
• Singapore-time boundaries, the precise percentage/refund convention and retained historical uncertainty are explicit v1.0 product decisions, not claims that every state is already mocked.
• Missing refund, conversion, empty, save-failure, unsupported-rule and other material error examples must be drawn and mapped to AC IDs before Ready.

Non-goals

Bank-statement reconciliation; live balances; credit-limit enforcement; payments or money movement; card applications; guaranteed rewards or confirmed payouts; guaranteed complete alert coverage; household sharing; business accounting; debit-card optimisation; native mobile apps; email-link sign-in; personal miles-goal tracking; universal best-card advice.

Constraints and data expectations

Captured alerts may omit recurring payments, instalments, refunds or other purchases. Explain this during setup. Retain category/MCC provenance and confidence. One user's correction must not silently rewrite another user's classification.

History remains accessible while the account is active. Original-email retention, deletion behaviour, data-removal controls and privacy wording must be agreed before a real-user pilot; no retention duration is invented here. Public mockups/specs contain example data only.

Assumptions, risks and open questions

Main risks: A plausible merchant category may differ from the bank's MCC; incomplete alerts may imply spare capacity that does not really exist. Separate category from MCC, disclose uncertainty, suppress unsupported advice and label allowance as estimated.

Decision log and source trail

Sources are Finance App channel messages, not independent proof of bank terms. All IDs below are stable and must not be reused.

• D1: One person/multiple cards, month and cycle views. Owner messages 801dce85-6c10-40d9-94fa-b4d3103e2067 and 800e3402-4057-49d1-be7a-1d7a49a0bd80. Accepted drawback: two period concepts to explain.
• D2: Tagged forwarding destination, uncertain captures excluded, incomplete spending estimates. Owner acceptance 138135cf-d284-487b-8aab-c0d5b4399bf9 and 48511a8e-1828-4850-94f3-efb2f4d03558. Accepted drawback: no statement-completeness guarantee.
• D3: Six planned banks, exact-product reward references. Owner 1751b5c6-7ecc-445c-9993-4ac8f645c95d. Accepted cost: validate each product separately.
• D4: Phone-first web app, Google sign-in first. Owner c3b61279-a615-4702-b979-000f478f3d93 and 0439ed7c-e578-4f9d-bafc-67d5bd5953e3. Accepted drawback: one sign-in route initially.
• D5: Rewards lead; cashback, miles, priority and conditional flags. Owner 0cb142e1-20df-40f3-828e-8a94c2527f1b and 7b596ae5-9945-4707-9c0e-94a8c7364e2f. Accepted limit: no definitive advice without evidence.
• D6: Multiple category tags; spend-based bonus progress; all transactions; remove personal miles goal. Owner d829509a-eaea-4c41-9155-139947be6753 and 0c924301-4ff8-4357-8d0c-d48084ac3d93.
• D7: Original blue design, DM Sans only. Owner 90656446-dad9-4dbe-8a06-9e2f6c08f3cb. Earlier visual studies rejected.
• D8: Monthly/cycle charts, card wrapper/images, MCC per purchase. Owner a2200548-b248-4c3f-b3ab-ec0facafd011 and 43e055a7-9f7b-4e01-8fbe-0d8bd30d3367.
• D9: Compact Home with total month spend then allowance per card; direct card history links. Owner 2e090a31-2691-4f01-8276-887b3b266cfa. Pia's disclosed calls in result da7815d2-4d62-4862-92eb-0dc636073509: red for caps only; tier completion stays blue; remove large Home recommendation. These were product calls, not separately recorded Owner instructions.
• D10: Rename Optima and add eligible percentage throughout history. Owner d2173078-ce78-4f64-9504-0f8fe3fc81f3.
• D11: Review through transaction pop-ups, no dedicated Review page. Owner 35c7a791-6b9c-4f1b-93b8-bcaf9b794459, followed by approval dff96fd9-b811-45bc-b7ef-fc3ba041e4dc.
• D12: New Pia v1.0 decisions: percentage uses captured purchase amounts including unclear eligibility, credits remain separate from the ratio, no percentage with no purchases, historical uncertainty retained. Reason: prevent incomplete data/refunds from producing misleading percentages. Accepted drawback: net spend and purchase-share figures need different labels. Additional state mockups required before Ready.

Handoff

This PRD defines user behaviour. Implementation choices stay with the CTO. Existing technical proposals are not evidence of delivered functionality. Next readiness work is Q1–Q6 and Q10–Q12. Changes to these requirements must receive a version and decision-log entry.

Appendix A · Singapore reward mechanics research

Research date: 2 November 2026. Fact means supported by the linked issuer material; Decision means Optima behaviour; To validate means insufficient evidence for a production estimate. This is a coverage framework for the planned six banks, not an exhaustive catalogue of every Singapore card, promotion or future rule. Exact supported cards still depend on Q1. General terms, product terms, amendments and campaign terms must be checked together before enabling a product.

A1 · Confirmed issuer examples

These facts establish that the mechanisms exist. They do not establish every exclusion, conversion, posting allocation or campaign combination for these products. Dates above are issuer dates where stated; access date is not substituted for an effective date. No card-specific estimate becomes supported solely because its product appears in this table.

A2 · Coverage checklist and phase boundary

Decision: For each supported pilot product, Phase 1 must cover every applicable standing condition below or clearly mark its reward estimate unsupported. Do not flatten an unsupported rule into a simple cap. Broader card coverage is P1. The checklist is for verification; it does not add all Singapore cards to Phase 1.

To validate: quota-limited offers, unfamiliar rule combinations and issuer discretion cannot be exhaustively inferred from alerts. Unsupported mechanisms must retain captured spending but withhold a confident reward/allowance estimate. Retaining the original email does not prove that all required conditions are present in it.

A3 · Display and calculation decisions

1. Separate three amounts: captured spend; spend that qualifies for a minimum; and spend/points consuming a bonus cap. Reward-bearing amounts after blocks can differ again. None replaces another.
2. Home stays compact but truthful: a simple card may show one amount; a complex card shows labelled category allowances and any unmet minimum/count condition. No headline sum of independent category capacities. Full conditions remain on the detail page.
3. Do not imply a guaranteed “safe extra spend” from points capacity: show a spend equivalent only when the verified rule makes it reliable. Near a block or cap boundary, explain the rounding and preserve native remaining points/cashback.
4. Fix the two-colour meaning: blue is the bonus-covered portion, amber is base-only/excluded/rounding remainder, grey is unresolved or conditional. Use text reasons. A purchase can have more than one portion. Threshold progress is a separate display; a minimum qualifying purchase need not earn a category bonus.
5. Minimum and cap status coexist: minimum met is positive; cap exhausted is red for that allowance. Avoid a blanket “switch cards” statement where base rewards or another category remain available. No additional spending is recommended solely to chase a tier.
6. Estimated rewards are not received rewards: show estimated earned and conditional amounts separately. Future bank-confirmed credit evidence, if supported, needs a distinct label and date. Alert-only capture does not establish payout, redemption or the user's airline balance.
7. Historical changes are explainable: retain captured facts, user corrections, dated rule and reason for revision. Never apply today's rate to last month's purchases silently. Keep spending history and reward-period history distinguishable.

A4 · Options and decision

A5 · Readiness changes and decisions

• D13: User request a837d3b1-ab77-47ed-8b8c-45e99047b335: research minimum/cap examples, multiple category limits and S$5 transaction rewards. Chosen response: precise labels, sourced mechanism coverage and F-05.AC6–AC16 plus linked display/history criteria. Accept extra row space for correctness. S$793 of a S$1,000 maximum means S$207 capacity, while S$793 of a S$1,000 minimum means S$207 still required. The user's 10 miles/S$1 remains an illustrative fixture, not an issuer claim.
• D14: Refine bonus-share reporting to covered portions after caps/blocks and disclose conditional portions. Reason: a whole purchase classified as successful can conceal wasted bonus capacity. Accepted drawback: percentages may differ from category-only percentages. Historical estimates must show a revision explanation; this is an explicit v1.1 change to D12/F-10, not an unchanged formula. Mockup percentages remain illustrative and have not been recalculated for these new cases.
• Q11 · Blocks Ready for affected pilot cards: Resolve rounding/aggregation order, cap allocation, retrospective tier qualification, posting-date evidence, external conditions and late refund behaviour against each pilot product's complete dated terms. Research examples are not a finished card catalogue.
• Q12 · Blocks Ready: Add and test mockup states for dual minimum/cap, multiple allowances, reward-block loss, a partly covered purchase, quarterly amount/count qualification and unknown payment/account condition. Map to the new AC IDs. Current mockups remain v0.16.
• Q5 remains open: CTO pressure-test effort, cost and risk for these additions and existing P0s before Ready. No delivery date or budget has been inferred from the research.

The fixed Phase 1 feature set remains F-01–F-12, with the above criteria now part of acceptance for supported pilot products. Status remains not Ready for implementation until the stated gates close.