Hi all, Following up on my earlier introduction (the CIF taxonomy mapping against FINERACT-1744, 2304, 2188, and 2457), I ran a related check on a different dataset that raised a question I don't have the codebase knowledge to answer myself, so I wanted to ask here rather than guess.
The check: on a real sample of PaySim transaction data (not Fineract's own data, a separate mobile money dataset), I looked for cases where a transaction was recorded as complete but the account balance never actually changed, and nothing flagged it as an error. Out of the anomalies found, when normalized by transaction volume rather than raw count, TRANSFER showed a meaningfully higher rate than CASH_IN, roughly 6x (0.77% vs 0.12% in this sample, though the TRANSFER count itself is small, 4 out of 522, so I'm treating it as a signal worth investigating, not a confirmed pattern). That raised a genuine question for me: in Fineract's own architecture, does a TRANSFER (moving funds between two accounts) go through a meaningfully different validation-to-commit path than a CASH_IN (funds entering a single account)? If TRANSFER involves more steps, more services, or more places where validation and commit could become separated in time, that would be a plausible structural reason for exactly this kind of pattern to show up more there, independent of whatever caused it in the PaySim data specifically. I don't have a strong sense of whether this maps onto Fineract's actual transaction handling at all, it may not, PaySim and Fineract are very different systems. But if anyone who knows the transaction processing internals has a quick read on whether transfer-type operations here involve a longer or more distributed path between validation and persistence than single-account operations, I'd genuinely value hearing it, even a "no, they're handled identically" is a useful answer. Thanks, Oludele
