What's New in MyFam360 — Credit Cards, AskAI History, Trip Splits, and Reimbursements

Most product updates don’t change how you use an app. They polish a corner, fix a glitch, rename a button. Useful, but not memorable.

The last few release cycles of MyFam360 have been the other kind — the kind where four parts of the product now do something they couldn’t do before. If you opened the app today after a few weeks away, here’s what would actually feel different.

This post walks through the four areas where the change is real: the Credit Card Manager (now closed end-to-end across seven phases), AskAI History (durable, searchable, re-runnable), Trip Splits (proper payer attribution + persistent guest participants), and the Reimbursement Flow (source-linked settlements with batch mark-paid and income auto-match).

Each section below summarises the change. If you want the deep-dive on any one area, the dedicated posts are linked inline and in the See Also section at the end.

If you’re new to MyFam360 entirely, the step-by-step guide to setting up your family budget is the better starting point. This post is for users who already have a budget and want to know what the recent updates actually do.

---

1. The Credit Card Manager Is Now End-to-End

If you carry two or more credit cards — one for online, one for groceries, one with a Flipkart cashback, one with a Tata Neu pass — you’ve probably done some version of this dance:

• Forgotten which card maximises rewards for a given merchant
• Missed a statement due date and picked up a ₹500 late fee plus interest
• Cancelled a card with a ₹500 annual fee because you couldn’t tell whether the rewards justified it
• Ignored a promo email from your bank because reading 12 SMS-style emails a month is exhausting

The Credit Card Manager is built to make all four of those problems go away. It’s now shipped across seven phases (v2.6 through v2.11) and the entire track is closed. There are seven deep-dive posts on individual parts — foundation, statements, payments and the impact preview, the rewards rule engine, rewards redemption and points expiry, promo email auto-import, and annual fees and the worth-keeping verdict.

Add a Card in One Step

Tap Credit Cards in the sidebar, then Add Credit Card. The 4-step flow asks for the card’s nickname (e.g., “HDFC for groceries” — this is what you’ll see everywhere in the app), the issuer’s billing cycle day, the credit limit, and any joint cardholders. Behind the scenes, MyFam360 ensures there’s a family-scoped Credit Cards account group and links a mirror account for the card automatically.

This mirror is important. Every expense you log against the card writes to the mirror’s balance, which is what the rewards engine reads later. You don’t have to do anything to set it up — it just exists once the card exists.

Statements Materialise Themselves

You don’t have to create a statement manually each month. A scheduled job at 02:00 UTC materialises the previous billing cycle for every active card on its billing-cycle day, freezing total_due and minimum_due. If you’d rather enter an issuer statement directly (because the cycle dates don’t match what MyFam360 projected), there’s a Manual Statement flow that accepts the exact statement_month and rejects duplicates.

The statement view shows a min-paid amber banner when only the minimum was paid and a projected-exhaustion banner if revolving the balance forward will tip the card over its limit before the next cycle.

Recording a Payment Shows You the Impact First

This is the part that’s easy to miss but useful. When you tap Record Payment (either the per-card icon on the Credit Cards page or the CTA from the Dashboard widget), the modal gives you three amount options as radio buttons:

• Minimum due — what the issuer requires
• Statement balance — pay it off in full
• Custom — type any amount

Underneath, a debounced (300 ms) impact preview updates as you type. It shows:

• Revolving balance after — what the card will carry forward
• Projected finance charge — what the bank will charge in interest if you only meet the minimum
• Projected status — paid / min_paid / open

The preview is purely read-only. You can model “what if I only pay ₹2,000?” without actually paying anything. When you confirm, MyFam360 records the payment, bumps the statement’s paid amount, recomputes the status, decrements the card’s current outstanding (capped at zero), and writes audit log entries.

The Notification Set That Matters

Five credit-card events run on a dedicated 02:30 UTC dispatcher:

Event	When it fires
credit_due_soon	T-3 days and T-1 day before due date
credit_overdue	T+1 day and T+7 days after due date
credit_min_paid	When you’ve only met the minimum
credit_payment_recorded	Synchronous on payment
credit_high_utilization	When utilisation exceeds 80%

Each event is idempotent per (family_id, statement_id, event_key, dispatch_date), so you won’t get five “due soon” notifications for the same statement.

The Calendar page also click-throughs: a credit_due_date event opens the Record Payment modal directly, with the statement pre-loaded.

The 8-Card Rewards Preset Library

This is the differentiator. MyFam360 ships a preset library covering eight common Indian cards:

Preset key	Card
hdfc_millennia	HDFC Millennia
hdfc_moneyback_plus	HDFC MoneyBack+
sbi_simplyclick	SBI SimplyClick
icici_amazon_pay	ICICI Amazon Pay
flipkart_axis	Flipkart Axis
axis_magnus	Axis Magnus
tata_neu_plus	Tata Neu Plus
tata_neu_infinity	Tata Neu Infinity

Apply a preset (Rewards tab → Apply preset) and the rule structure is seeded — online cashback rates, merchant-tier multipliers, online sub-caps, monthly card-wide caps. The engine then sources spend exclusively from your logged expenses through the card’s mirror account, so the rewards number is your real spending, not a generic estimate.

If your variant differs from the preset — say a different earning rate on online travel — you can edit any rule inline. Rule-level cap exhaustion falls back to the base rate; the card-wide monthly_cap is a hard ceiling.

Quick Add From Card Context

If you’re already on the Credit Cards page and want to log an expense to a specific card, the per-card “Add expense” button opens Quick Add with the mirror account pre-selected and an explicit credit_card_mode intent. One tap, no account picker, no confusion about which mirror this card uses. Both desktop and mobile have action parity.

Promo Email Auto-Import (Family+)

The most futuristic part. You can opt in to a per-family forwarding address (promos+<family_uuid>@…) and forward promo emails from your bank to it. At 04:45 UTC daily, a parser runs over the staged inbox:

• Issuer-specific parsers handle HDFC, SBI, Axis, and ICICI promo formats
• A generic regex fallback handles ~40 common patterns
• An LLM-assist fallback handles the rest

Parsed offers land in a Promo Staging review queue with status pills (proposed / accepted / rejected) and bulk confirm/reject actions. There’s a monthly cap (50 rows per family per month) and a global opt-in gate (credit_promo_email_import_enabled).

The Pro+ tier also surfaces the forwarding address as a copy-able widget in Settings with a monthly usage counter.

Worth Keeping?

For Family+ users, the Worth Keeping verdict compares the card’s accumulated rewards against its annual fee and tells you, in plain English, whether the card is paying for itself. The annual-fee scheduler runs daily at 03:35 UTC, idempotent per (card_id, year), and writes annual_fee_charged / annual_fee_waived audit rows.

---

2. AskAI History — Durable, Searchable, Re-Runnable

Until recently, AskAI was a fire-and-forget interface: ask a question, read the answer, and if you wanted to compare it to last month’s answer you had to re-ask from scratch.

That’s now fixed. The full architecture (server-backed persistence, pinning, daily cap mechanics, privacy guarantees) is covered in the dedicated AskAI History deep-dive.

Every Question and Answer Is Saved

A new ask_ai_history table persists every AskAI interaction server-side. The Insights → AskAI tab now opens with a list of your past questions grouped into Today, Yesterday, and Older, with a search box that filters by question text.

Pin Your Favourite Questions

If you ask the same monthly question — “What’s my biggest discretionary spend?”, “Did I stay under budget this month?” — pin it. Pinned questions sort to the top and survive history clears.

One-Click Run Again

Every saved answer has a Run Again action that re-issues the same question against current data. This is how you compare months: ask once, pin, and re-run on the 1st of every month. The result lands as a new history row, so you keep the trend rather than overwriting the old answer.

A duplicate-question guard prevents you from accidentally creating identical entries when you manually re-ask, so the history stays clean.

The Daily Cap Doesn’t Reset When You Clear History

This is the subtle bit. AskAI is capped at 3 requests per family group per UTC day. The cap counts against a durable audit_logs count (entity_type="ask_ai_request"), not against the ask_ai_history table. That means clearing your history does not give you back AskAI quota for the day. The default is conservative for a reason — these requests cost money to serve, and three thoughtful questions tends to beat thirty quick ones.

Privacy Hasn’t Changed

The minimization architecture is the same as before: AskAI never sees individual transactions, merchants, or account identifiers. Only aggregate payloads (category totals, monthly summaries) flow through llm_minimization_service.py into the provider. The full architecture is covered in the dedicated post on how AI features work without seeing your personal data.

---

3. Trip Splits Now Show Who Actually Paid

If you’ve ever travelled in a group of three and shared the bills, you’ll recognise this scenario: one person pays for the OYO room, another pays for the cab, a third pays for dinner. Later that night, somebody opens the app and logs all three on behalf of the group.

In the old model, every trip expense was attributed to whoever logged it. The actual payer was lost.

That’s fixed. The full walkthrough — including the new trip_guest_members table and how fair-share math handles guests — is in the Trip Splits deep-dive.

Manual-Paid Markers Are Preserved

When you create a shared trip expense and mark one of the split rows as “paid manually outside MyFam360” (because Person A actually handed over the cash), that marker now persists. The expense knows who paid in addition to who logged.

The Trip Expenses View Shows Payer + Logger

On the Trip Detail page, every transaction row now shows Paid by explicitly. If the payer is different from the person who logged the expense, a secondary Added by line appears below in smaller text. This works on desktop and mobile.

For groups where one organiser tends to log everyone’s spend during a trip, this resolves the worst source of “wait, who actually paid for the cab on the 14th?” confusion.

Guest Participants Are Now Real

Earlier, trip “guests” (non-MyFam360 friends or relatives on the trip) were stored as a comma-separated display string. They didn’t count toward fair-share math or member counts in any rigorous way.

A new trip_guest_members table now stores guests as durable trip members, with a backfill migration that converts the old display string into proper rows. Guest names participate in:

• Fair-share calculations (a 3-member trip with 1 guest splits 4 ways)
• Member-count totals in trip summary
• Trip expense splits, so a guest can owe or be owed money inside the trip’s bookkeeping

You can settle with a guest through the same Settlements flow as with a logged-in member, except the guest’s “settlement” is functionally a closure note — you mark the chain paid manually once you’ve squared up in cash.

For the full settlements walkthrough, the shared expenses guide covers the underlying mechanics.

---

4. The Reimbursement Flow

Settlements have always existed in MyFam360. What was missing was the trace from a settlement back to its source.

If you logged a recurring grocery expense, and your partner reimbursed you for half of it three weeks later by transferring money into your account, the old model had no way to know that the recurring expense, the settlement, and the inbound income were three faces of the same event.

The new flow links them. The model details (source FK columns, the backfill script, income auto-match, batch mark-paid, and reminders) are in the Reimbursement Flow deep-dive.

Settlement Source Links

Settlements now carry three nullable foreign keys:

• source_expense_id — populated when the settlement was created from a one-off expense
• source_recurring_id — populated when the expense was generated from a recurring template
• paid_via_income_id — populated when an income transaction settled the chain

A one-shot backfill script (scripts/backfill_settlement_source_links.py) ran in dry-run-first mode against existing data to populate these links for historical rows. New settlements get linked at creation time — recurring_service._generate_expense_from_template and expense_service.create_expense both stamp the source link.

The Reimbursements Page

There’s now a dedicated Reimbursements route in the sidebar. It opens to two summary cards (Owed to you, You owe), a filterable list of outstanding chains, and a batch Mark Paid modal.

Each chain shows the underlying source — the original expense or recurring template — so you can tell at a glance whether you’re chasing a one-off ₹1,200 grocery split or a recurring rent share.

Batch Mark-Paid

When somebody pays you back for multiple chains in one bank transfer (₹6,400 to cover groceries, fuel, and a movie), you don’t have to mark each chain individually. Select the chains in the list, tap Mark Paid, confirm. The modal flattens the selection into individual settlement IDs under the hood and processes them atomically.

Income Auto-Match (Pro+)

For Pro and Family+ plans, when you log an income that looks like a reimbursement (matching amount, matching member), MyFam360 surfaces a banner in the income form: “This looks like a reimbursement for these chains — match them?” Confirming the suggestion ties the income to the chains via paid_via_income_id and marks them settled, all in one action.

The matching correctness was hardened in v2.2.0 — the suggestion will only fire if the income total exactly equals the chain total, to prevent partial matches from accidentally closing a chain.

Reminders (Pro+)

If somebody owes you and forgets, you can send one reminder per chain per day (Pro and Family+ only). A weekly digest acts as a fallback so reminders don’t pile up. Reminder opt-out lives in Settings.

---

What This Means For You

If you only have time to do one thing after reading this:

• If you carry credit cards: add them in the Credit Card Manager, apply the preset if your card is in the library, and let the statement materialisation + reward tracking run for one cycle. By the next billing date you’ll have a real number for what your cards are earning versus what they’re costing.
• If you ask the same financial questions every month: ask one in AskAI, pin it, and use Run Again as your monthly review trigger instead of starting from scratch.
• If you split costs with a partner, family, or trip group: re-open one recent shared trip and look at the new Paid by / Added by lines to see whether old expenses are now attributed correctly.
• If somebody owes you money and you’ve stopped chasing it: open the new Reimbursements page, find the chain, and either mark it paid (if it’s already been settled offline) or send one reminder.

These four updates aren’t independent. Together they sit on top of the same money flow — log an expense against a card, see it count toward rewards, share it with a trip member, settle it later when they pay you back, and ask AskAI whether your card is still worth keeping. Each part was already in the product. The recent work was making them talk to each other.

---

See Also

Deep-Dives on the New Features

• Credit Card Manager — The Foundation
• Credit Card Statements — How the Cycle Closes Itself
• Recording a Credit Card Payment with the Impact Preview
• How the Credit Card Rewards Engine Works
• Credit Card Rewards Redemption and Points Expiry
• Credit Card Promo Email Auto-Import (Family+)
• Credit Card Annual Fees and the Worth-Keeping Verdict
• AskAI History — Pin, Re-Run, and Why the Cap Doesn’t Reset
• Trip Splits and Guest Participants in MyFam360
• The Reimbursement Flow in MyFam360

Adjacent Guides

• How to Set Up Recurring Expenses in MyFam360 — the recurring template that now stamps a source_recurring_id on generated settlements
• How to Track and Settle Shared Expenses Between Family Members — the underlying settlement mechanics
• How to Use Savings Goals in MyFam360 — covers goal-linked recurring expenses, which interact with the new Credit Card flow
• How AI Features Work Without Seeing Your Personal Data — the architecture behind AskAI’s privacy model
• How to Read Your Spending Reports in MyFam360 — where to find the rewards summary and reimbursement trends in the Reports page