Coinbase Ireland’s Safeguarding Case: Finding Deposits Missing from the Calculation

01

From the enforcement announcement to a daily calculation

On October 22, Ireland’s central bank announced an October 21 settlement with Coinbase Ireland Limited (CBIE) over e-money safeguarding failures. A reprimand and EUR 3,252,618 penalty require High Court confirmation. A useful question comes before checking the bank balance: which deposits entered the amount against which that balance is being compared? [Announcement]

The safeguarding amount is not necessarily a single number displayed on a bank screen. Deposit records have to be collected, the nature of the funds established and the appropriate balance produced. If one record disappears along the way, even flawless arithmetic in the final report can understate the requirement. If a record appears twice, the requirement can be overstated. Several processing steps may sit between the deposit history a customer sees and the daily calculation the provider uses.

The four fictional deposits below let readers check those differences on paper. Following their transaction identifiers, readers can introduce an omission, a duplicate match and two errors that offset one another, separately. The final check concerns more than the correct sum: it also asks which identifiers should survive exactly once. The example does not certify a reader’s own safeguarding arrangements, but it turns unanswered questions about a provider’s explanation into specific checks.

Work back from the balance to the deposits behind it

Customers will often receive a description such as “funds are segregated” or “balances are reconciled daily.” That description does not reveal where a deposit goes in the daily calculation when its customer reference cannot be matched. A more focused question is what evidence brings that deposit into the calculation before it appears in the customer’s account, and where the unresolved record is kept. That makes it possible to compare a reassuring statement with an explanation of the calculation.

The consequences extend beyond customer enquiries. Businesses using a payment service may face additional work confirming sales receipts or deciding on refunds if deposit matching is delayed. Providers bear the cost of investigating exceptions and keeping the necessary funds in place. As operations add countries or currencies, the ability to construct the right transaction population as quickly as volumes grow can affect the operating cost of expansion. For example, when a merchant automatically matches deposit identifiers to invoices, the time at which its provider resolves an unmatched receipt can affect how many statement entries the merchant must reprocess.

This case cannot by itself establish the direction of crypto prices or a particular company’s present ability to process withdrawals. An enforcement action about safeguarding calculations and a token’s market price require different evidence. The task here is to trace deposits into a daily comparison amount. Explaining the possible errors with a few records helps readers understand weaknesses that a published aggregate alone would leave hidden.

02

SG Group View: The safeguarding amount starts with selecting deposits

A balance comparison needs at least two numbers: the amount that must be safeguarded under the applicable conditions, and the amount verified as available for that purpose. If the deposit population generating the first number is incomplete, obtaining the second number from the bank with greater precision will not repair the comparison. Returning to the deposits exposes errors that more frequent reconciliation alone would not correct.

A “population” means the transactions being aggregated under the same conditions. It is not simply the sum of every line downloaded from a bank. The purpose for which funds were received, the relevant entity, the time of receipt and the status of cancellations or refunds can determine which records belong. Once the criteria are settled, inclusion and exclusion decisions need to remain attached to transaction identifiers. Amounts alone cannot reproduce the selection.

If a calculation understates the requirement, someone relying on that number may conclude that enough funds have been set aside. An overstated requirement may instead prompt a decision that additional funding is needed. This describes a route from a calculation error to a decision; it is not a claim that the provider in this case made those particular transfers. The actual effect also depends on whether another control intercepted the error.

Changing the requirement changes the apparent room to use cash

In considering service operating cash, the calculated requirement should not be equated directly with cash the company can spend freely. Funds in a bank account may still be subject to conditions or transfers in progress. Equally, correcting an overstated requirement does not necessarily make the difference immediately available for expenses. Repairing the deposit population is a separate step from authorising a payment, and it does not create an accounting profit.

The effect on business economics is clearer when expressed through work and the use of funds, rather than by converting a fictional difference into profit. Longer exception investigations increase staff workload and may delay customer responses. Setting aside additional funds against an overstated requirement can keep them unavailable for other purposes. The cost depends on rates, contracts and investigation time; it cannot be calculated from a reported shortfall alone. Unresolved record counts, resolution times and repeated processing of the same deposit after a correction provide clues to where the work originates.

When comparing expanding payment services, readers can ask how their calculations behave when exceptions increase, as well as how many transactions they process. Do required deposits remain in the population, do duplicates stay out, and does an unresolved record have a route to investigation? Stable handling could reduce the need to force totals into agreement manually as volumes grow. Adding an adjustment to the final balance alone can leave the same problem ready to recur with the next deposit.

For working back from provider descriptions to contracts, Check exchange contracts, custody and withdrawals. Read withdrawal terms separately from the deposit arithmetic.

03

What two observations can—and cannot—establish

The Notice links historical calculation errors to mismatched input times and omitted unallocated funds; it records no evidence of realised consumer detriment. [Settlement Notice]

The fictional example below stipulates separate evidence of purpose even for a deposit with no customer match. An unidentified customer and an unknown business purpose are different questions. Including or excluding all records merely because they share a label would collapse those questions into one. Keeping the matching result separate from the basis for inclusion makes each decision traceable.

The calculation cutoff can provide another entry point for omissions. Bank receipts and customer balances extracted at different times may leave a later receipt without a corresponding customer record. If the process then keeps only matching rows, a timing difference becomes a missing deposit. A customer reference added later may repair the total, but deleting the history of what the earlier calculation omitted would obscure the point at which the problem arose.

Distinguish a scale measure from a daily history

A maximum cannot establish an average, the number of affected days or the time to recovery. Before comparing scale through one measure, ask which question it answers. Reconstructing daily cash movements, for example, would require dated records and the timing of changes, not two shortfall observations alone. Precision in how a number is displayed does not establish that it measures the scope needed for the inquiry.

The matching mistakes below do not reconstruct a particular internal CBIE procedure. The fictional example demonstrates the arithmetic of changing the rules by which records are combined. Assessing actual causes and scale would require the relevant records, calculation specification and history of remediation. Agreement in the example cannot establish that actual transactions used the same sequence or conditions.

When evaluating remediation, a useful clue is what replaced the earlier calculation. Can a qualifying deposit without an identified customer survive through another route? Can original statement lines be followed into the output count? The answer also appears in how unresolved records carry into the following day. Reading whether omitted deposits can be kept from disappearing again is closer to this case than ranking operational quality by the monetary penalty alone.

04

Build the correct population from four fictional deposits

Figure 2 contains four deposits received by a bank before one common cutoff. D1 is EUR 100 from customer A, D2 is EUR 60 from B, D3 is EUR 20 from U whose customer match is unresolved, and D4 is EUR 20 from G. The total is EUR 200. These amounts and identifiers are entirely fictional, not CBIE transaction records. Refunds, fees, currency conversion and opening balances are excluded so that the example isolates the construction of a required amount from four deposits.

The mapping assigns A and B to CBIE and G to another group entity. U has no match to an ordinary customer reference. For D3, however, assume that evidence independent of that reference establishes receipt for CBIE e-money and its inclusion in the relevant funds. That purpose and eligibility are essential premises. The example does not put every unidentified payment into CBIE’s calculation merely because its sender cannot be identified.

Under those conditions, CBIE’s population consists of D1, D2 and D3: EUR 100 + EUR 60 + EUR 20 = EUR 180. D4 is excluded from CBIE’s population as a receipt belonging to another entity; its existence is not deleted. Excluding a deposit from this calculation is different from saying that no bank receipt occurred. Keeping all four original records while selecting three makes it possible to explain the difference between group receipts and CBIE’s amount through a specific deposit.

A missing customer reference need not erase evidence of purpose

An exception ledger for D3 can connect the original bank-statement identifier, the evidence of purpose and the reason customer matching remains unresolved. Identifying the customer later does not turn the original receipt into a new deposit. Moving it into ordinary customer processing therefore needs to retain the identifier and avoid counting it again while the exception entry remains active. In a real operation, the evidence and authority required to establish purpose depend on contracts and applicable conditions; text in a table is not a substitute. Explanations added later should also remain distinguishable from evidence that existed on receipt. New evidence for a decision does not change the date on which the funds arrived.

Reading each original amount once before aggregation is useful in this small example. D3 and D4 have the same amount but represent different deposits. Equal amounts do not justify deleting one as a duplicate, and different customer labels alone are not sufficient proof of distinct funds. The transaction identifier traces how a record from the bank expands into several output rows or drops out. It serves a different purpose from a customer’s display name.

Readers can first copy the four rows and mark only three as belonging in CBIE’s population, then add their amounts. Each of the next three mistakes should be tested by returning to those same original four rows. Carrying an uncorrected error into the next experiment would obscure which change moved the total. This table produces the requirement only: it supplies no qualifying safeguarded account balance. The EUR 180 answer alone therefore cannot establish a shortfall.

05

Keeping only matched rows makes EUR 20 disappear

The first mistake occurs when combining the deposit list with the customer mapping and keeping only rows with a matching customer. In data processing, that is an inner join. D1 and D2 survive because their customers match. D3 has no matching customer row and disappears even though separate evidence supports its eligibility. D4 matches but is excluded because it belongs to another entity. The result is two records totalling EUR 160.

Checking only whether the EUR 160 has been added correctly will not find this error. Nothing is wrong with the amounts in the two surviving rows. The original three eligible deposits must be compared with the two output records to locate where identifier D3 vanished. Tracing bank records forward to the final population complements checking that the output rows are valid. A record missing from the output cannot be recovered by inspecting the output alone. A valid exclusion can be supported with its reason. But if independently qualified D3 disappears solely because customer matching failed, the calculation route needs repair.

The repair is to add independently qualified D3 once through an exception route to D1 and D2 selected by ordinary customer matching. That restores three records and EUR 180. There is no need to rewrite D3’s customer field as A merely for convenience. Such a change could repair the sum while concealing the unresolved customer identity. The state of customer identification and the decision to include funds should not be forced into a single field.

Connect an unmatched exception to the normal calculation

The exception route also needs to be checked for overlap with ordinary processing. If D3’s customer is identified the following day, that same deposit may enter the normal route. Continuing to add its exception entry would turn an omission into a duplicate. Recording when the exception closed and which transaction identifier passed into normal processing prevents completion of an investigation from being mistaken for the creation of another receipt.

Adding all bank receipts would not repair this example either: it would include EUR 20 from D4 that does not belong to CBIE. The choice is not simply whether to use the customer mapping. The calculation needs a route for unresolved customer matches that preserves evidence of eligibility. If later evidence establishes that D3 was received for a different purpose, the population must change accordingly. An exception record is not permission to include funds unconditionally.

Figure 3 shows where the two decisions separate. Establish receipt and eligibility first, then match the customer. If matching fails, retain a deposit whose eligibility has already been established through the exception ledger, and aggregate it once alongside ordinary matches. Only then compare the result with separately verified safeguarded funds. The sequence does not automate a regulatory compliance assessment; it shows a calculation route that keeps D3 from disappearing in this example.

06

Two mapping rows can count one deposit twice

Return to the original four receipts before testing the second mistake. D3 is now correctly included through the exception route, and D4 remains excluded. Only A’s mapping changes. Assume that, instead of one applicable entry, there are two rows with overlapping effective periods, both selected at the same cutoff. No second customer or extra receipt has appeared. The same deposit simply matches two separate rows in the mapping.

D1’s EUR 100 then appears twice in the matched output. D2’s EUR 60 and D3’s EUR 20 each appear once, producing EUR 100 + EUR 100 + EUR 60 + EUR 20 = EUR 280. The difference from the correct amount is the extra copy of D1. Neither the bank statement nor any original deposit amount has changed. Missing the stage at which matching multiplies rows can produce an overstated sum while the user still believes that numbers built from bank data must be accurate.

There are four output rows but only three distinct original deposit identifiers. That difference provides a starting point for investigation. Count how many rows connect to D1 and trace the reason back to the mapping. An increased row count is not automatically an error: a legitimate process may split a receipt into components. The amounts allocated to those components also need checking. In this fictional example, the full amount is copied into each row rather than divided, which inflates the total. Checking whether the component amounts return to the original deposit, or instead attach the full amount repeatedly to the same statement record, helps distinguish a legitimate breakdown from copies.

Look for multiplying identifiers, not merely equal amounts

Repairing the result by amount alone can introduce another error. Collapsing equal amounts may remove separate deposits that happen to be identical in value. Keeping only the first row per customer could discard legitimate repeat payments by the same customer. The comparison should follow the original deposit identifier and the total amount attributed to it. Here the two D1 rows exceed the original EUR 100, and the overlapping mapping that causes that result needs correction.

Simply choosing the mapping row with the latest date may also lack sufficient justification. A registration date and an effective date can lead to different choices. If the correct mapping remains unresolved, the ambiguity should go to investigation while the deposit whose eligibility is established survives through a defined route. That separates an unresolved mapping decision from the existence of the original receipt. An exception route still needs protection against overlap with ordinary processing.

If an overstated calculation informs a funding decision, a provider might seek to set aside unnecessary additional cash. The resulting funding constraint and investigation work could carry economic costs. An inflated calculation alone, however, does not prove that extra cash was actually transferred. A check before approval could limit the effect to corrective work. After finding a duplicate, tracing which decisions used the erroneous population helps establish the relevant cost.

07

Offsetting errors can leave EUR 180 looking correct

The third test also starts with the original four deposits. Keep D1 and D2 once each, omit D3 and mistakenly include D4 from the other entity instead. The calculation becomes EUR 100 + EUR 60 + EUR 20, the correct total of EUR 180. The omitted and wrongly included amounts happen to be equal. A’s mapping is restored to one row, so the duplicate from the previous section is absent. This isolates what an aggregate comparison can miss.

The output contains three rows with no duplicate identifiers. It therefore passes separate tests of the total, the record count and identifier uniqueness. Finding the error requires comparing the identifiers in the correctly selected population with those in the actual output. D3 appears only in the expected set and is missing; D4 appears only in the output and is an unexpected inclusion. Their substitution shows why membership checks are needed alongside aggregate checks.

Even if the amount on the other side of the comparison were also EUR 180, that would not establish that the calculation was correct. The error in which deposits generated the requirement would remain. Equally, the substitution alone would not prove a EUR 20 customer loss. This table does not supply the actual location of funds, their eligibility for safeguarding, or the history of payments and recovery. Agreement in the arithmetic, customer rights and recovery outcomes each require their own evidence.

The same total can contain the wrong three deposits

Reporting only a net difference makes the two errors appear to shrink to zero. Missing and unexpectedly included transactions should therefore remain separate. Adding D3 and removing D4 have opposite effects on the sum but are different corrections with different reasons. Performing only one would change the total. Treating an unchanged amount as grounds for doing nothing, or adding a single adjustment to force a total into agreement, would leave the incorrect transaction population intact.

The substitution can also make later investigation of individual records more costly. Daily aggregates provide no obvious starting point because they balance. If a customer enquiry sends staff back to the original receipt and the identifiers used in the calculation were not retained, staff must reconstruct where it disappeared. The answer is not to publish confidential customer information. It is to preserve enough detail internally to connect original statement records with calculation outputs. Longer reconstruction can also delay an explanation to the customer. Discarding detail once the aggregate agrees can therefore carry a later customer-service cost.

The three errors assign distinct jobs to the checks. Tracing original receipts into the output looks for omissions; checking the amount attached to each deposit identifier looks for duplication; comparing the expected and actual identifier sets looks for substitutions. No single check replaces the others. Using the four-row example to see which check responds before and after each mistake allows readers to ask more precisely what a provider means when it says it performs reconciliation.

For the separate classification of crypto holders and redemption entities, Match holders to the entity handling redemption. It is a different framework from e-money.

08

An updated record is not another deposit

When an unmatched deposit later receives a customer reference, should the amount in the calculation rise? In this fictional example, separate evidence already establishes that D3’s EUR 20 relates to CBIE e-money, despite the missing customer reference. Completing the reference identifies the customer; it creates no further receipt. The first test is therefore that the population of eligible deposits and its EUR 180 total remain unchanged before and after D3 is updated.

Call the original D3 version 1 and the record with the completed reference version 2. Both must retain an identifier pointing to the same bank receipt. A calculation that selects version 2 and also adds version 1 counts money twice even though it reached the account only once. Preserving old versions does not mean summing every stored row. A manual check can expose this error by placing the transaction ID, version number and selected version alongside each entry.

Reproducing an earlier day also requires more than matching old receipts against today’s customer list. Preserve the inputs and lookup table used for that calculation, reproduce its original result and explain the difference from any corrected result transaction by transaction. If the original report was EUR 180 and remains EUR 180 after the reference is completed, the amount has not moved. D3’s transfer from an unmatched category to a customer category should nevertheless remain traceable. A correction with no monetary effect can then be reviewed.

Trace corrections and reversals to the original entry

Consider a further fictional test in which D2’s EUR 60 is reversed. Do not silently delete the original entry. Link the reversal to D2 and use supporting records to establish whether it represents duplicate data for the same receipt or an actual refund. Money leaving a bank account does not by itself extinguish the obligation owed to an e-money customer. The recipient and contractual treatment of the refund may change the required balance. Merely adding a row with the opposite sign does not settle that question.

If the reversal took effect after the calculation’s cut-off, first test whether the original, pre-cut-off EUR 180 can still be reproduced. A subsequent test reducing the amount by EUR 60 is a separate state, requiring evidence that the corresponding obligation also fell. On that additional fictional assumption, the result would be EUR 120. Inserting a later event into an earlier calculation can conceal the shortfall or error that existed at the time. A corrected report is easier to assess when the original result and the reason for changing it remain available side by side.

This test becomes particularly useful when the same process is run again. With identical inputs and selected versions, D3 should not be added again and a reversal should not be applied twice. Compare the selected transaction-and-version pairs as well as the total. If each rerun changes the answer, the update-handling process needs investigation before the calculation can be relied on. Running it more frequently does not resolve the problem; the process must specify which receipt is counted once.

09

Check the population against independent bank records

Once the required amount has been calculated, it must be reconciled with the cash supporting it. But deriving both a “required amount” column and a “funds held” column from the same summary is no independent check. If D3 disappeared from the source table, both columns would inherit the omission. Use bank statements or balance records as a separate starting point, connecting evidence of the receipt, its inclusion in the calculation and the location of the relevant funds.

Add the fictional assumptions of zero opening balance and no withdrawals, and the three CBIE-related receipts produce EUR 180. The group’s EUR 200 still cannot be called the same balance: D4’s EUR 20 belongs to another entity in the example. An actual reconciliation would also require the opening balance and records of refunds, transfers between accounts, fees and other movements. Comparing total receipts directly with a bank balance at a particular moment, without aligning these conditions, can make legitimate cash movements look erroneous.

The four amounts in the chart represent separate calculation states using the same fictional receipts and the same cut-off. They do not combine omission, duplication and substitution into one error state. A smaller total may point towards omission, and a larger one towards duplication, but even an answer of EUR 180 requires a membership check. Explaining, receipt by receipt, why D1, D2 and D3 appear once and D4 is excluded is more useful for other amounts than memorising the correct total.

Look for a different receipt hidden behind the same total

Record the outcome as omitted eligible receipts, wrongly included ineligible receipts and receipts counted more than once, rather than retaining only a net difference. Forcing unresolved entries into either category can manufacture a reassuring match. Show uncertain entries separately by count and value, and calculate how resolving their status would move the required amount. Do not merge a case such as D3, where the nature of the funds is established but the customer reference is missing, with a receipt whose status itself remains uncertain.

Bank statements alone cannot establish the entire obligation owed to customers. They evidence cash movements, but do not automatically explain issued e-money, pending redemptions or transactions awaiting posting. Comparing them with customer records and settlement status narrows down the reasons for a difference. Nor do several documents necessarily provide independent corroboration if all are copies of the same input; the check must return to the underlying records.

10

Test lookup changes with cases that pass and cases that stop

A test limited to checking that the repaired receipt is now correct is too narrow when changing the table that links customer references to entities. Fix the fictional lookup in which A and B map to CBIE and G maps to another entity, then prepare both inclusion and exclusion cases. Completing D3’s customer reference should retain funds that were already eligible. D4, referencing G, must remain excluded after the change. Testing only inclusion could approve a crude repair that admits everything.

When a test introduces two lookup rows for A, it must not cause D1 to be added twice. If a customer reference returns two candidates, either resolve which candidate is supported by evidence or stop the process for an ambiguous match. Automatically taking the first row is also risky: changing the row order could change the answer. Verify separately that the receipt has one transaction ID and that its lookup has a single justified match.

Test the treatment of a reference with no match. Independent evidence establishes that D3 belongs in the population, so a missing reference alone must not discard it. But extending that example to classify every unmatched receipt as CBIE e-money funds would also be wrong. The expected result is not a blanket rule to include all unmatched entries. It is that the process can incorporate separate evidence of the nature of the funds. Add a case where that evidence is absent.

Check that unrelated transactions do not move

Compare transactions with no monetary change as well as those changing the total. Completing D3’s reference moves it from an unmatched category to a customer category without changing its value. Changing G from another entity to CBIE, by contrast, could bring D4 into the calculation. Approval of the data change is not enough: evidence must establish why the funds’ attribution changes. Standardising names or migrating data should not automatically rewrite history as though the funds had always belonged to the same entity.

The test matrix also includes reordering rows and importing the same data again. Those operations should not be tested in the same way as completing a customer reference, which changes the breakdown. The latter should produce an explainable reclassification; the former should preserve both amount and membership. Change one input at a time to narrow the cause to reference matching, duplicate transactions or version selection. Combining numerous changes can let one effect conceal another.

A handful of passing examples cannot establish the correctness of every actual transaction. At a minimum, extract all entries whose inclusion changes under the old and new processes and separate intended changes from unintended ones. Then extend testing across affected deposit channels and customer types. A process that succeeds only for one bank or reference format cannot simply be assumed to work elsewhere. Differences between intake channels, as well as transaction volume, justify a broader test population.

For investigation and reporting of suspicious transactions, Trace inputs, investigation and reporting in payment monitoring. Keep reporting decisions separate from generating the fund amount.

11

Exception work and redemption: what accurate aggregation cannot resolve

Investigating unmatched funds also takes staff time. For a record such as D3, inclusion in the required amount can precede the separate task of finding the customer reference. If the nature of the funds itself is uncertain, additional evidence must first be gathered. Combining both states into one “unprocessed items” count obscures what action would resolve them. A falling count is no operational improvement if it results merely from dropping entries out of the calculation.

What a processing delay can establish

For a customer, the relevant gap may be between seeing a displayed balance and having the underlying receipt correctly reconciled. A prolonged reference investigation could require further exchanges to establish a refund recipient or process a redemption. Yet identity checks and fraud investigations can also delay transactions, so one delayed withdrawal does not establish a safeguarding shortfall. The specific service step affected by the receipt error must be identified.

The implications for financial markets are best approached through these business channels. Accurate aggregation could improve service economics if it reduces unnecessary transfers, exception investigations and provision for funding gaps. Conversely, investment in testing and reconciliation could increase costs in the short term. This announcement alone cannot establish the size of any effect on the parent’s earnings, customer outflows or crypto prices. Changes in fees or market pricing would require separate disclosures or observations.

12

Does a small difference justify a lighter check?

There is a practical argument for managing aggregate differences against thresholds rather than inspecting every small receipt with equal intensity. Investigating every discrepancy in the same way could divert staff from customer support or major incidents. Amount, age and frequency can reasonably determine the order of investigation. But prioritising investigations is a different decision from excluding eligible transactions from the calculation at the outset.

A small average difference says little about the experience of affected customers if errors concentrate on particular days or deposit channels. Numerous dispersed small discrepancies and one omitted large receipt call for different responses. An equally sized erroneous inclusion can also shrink the net difference. To assess scale, retain both the absolute difference and the records that were wrong in each direction, then examine how those errors cluster.

A second objection is that decentralising calculations across locations can itself produce inconsistent rules. A shared process can standardise the definition of a receipt, duplicate detection and correction handling. It may also provide testing that a small local team could not readily support alone. The fictional tests do not establish that centralisation is inherently dangerous. Extending a correct design across the business is a substantial benefit of a shared process.

Centralisation can help—and spread a shared error

A wrong condition in a common lookup can nevertheless affect several deposit channels using it. If adapting a reference format for one bank changes unrelated receipts at another bank, that is a reason to investigate the boundary of the shared process. Tests should show both that the repaired channel works and that IDs and amounts on unchanged channels remain stable. Simultaneous changes across many channels would justify examining common processing before attributing the results to individual customer actions.

Another objection is that a calculation failure is being given excessive weight when customer detriment has not been established. Whether customers suffered loss or inconvenience is indispensable to evaluating the actual outcome. Daily calculation tests serve a different purpose: finding conditions that could cause mistaken funding decisions before a loss occurs. Explaining a potential channel does not claim that a loss materialised. Showing which records failed a test is clearer than repeatedly describing the situation as dangerous.

Stricter tests can also create false alarms. Stopping a legitimate correction as though it were a duplicate increases pending work. The response should be to obtain evidence linking it to the original receipt, rather than quietly removing the exception. More detected items are not automatically better, nor does a zero-exception report prove success. A useful assessment asks whether the process can retain funds such as D3, exclude D4 and avoid double-counting a valid update at the same time.

For preserving the trail between inputs and results, Read how to preserve versions and supporting records. The explanation is public; the operational features it introduces are paid. It does not assess safeguarding compliance.

13

Reconstruct the population from seven fictional records

To try the comparison, write seven records on paper or in a local table. Four are bank receipts: D1 references A for EUR 100; D2 references B for EUR 60; D3 references unmatched U for EUR 20; and D4 references G for EUR 20. In three separate lookup rows, map A and B to CBIE and G to another entity. Add the stipulation that independent evidence establishes D3 as funds relating to CBIE e-money despite its unmatched customer reference. Those seven rows form the starting point.

First count the four bank receipts before consulting the lookup. Then write the transaction IDs selected for inclusion on a separate sheet, recording a single amount for each ID and a short reason for including it. Because the lookup cannot establish D3’s status, make clear that its inclusion relies on the additional stipulation. Record why D4 is excluded, so the difference from the sum of all bank receipts can also be explained. Leave the original four receipt rows unchanged until the check is complete.

Next, hide your first selected list and reconstruct the eligible IDs from the seven rows and additional stipulation. Compare records and reasons rather than copying the earlier answer. Even if the total is correct, check whether D3 and D4 have been exchanged between the lists. Tallying the number of times each row was used also reveals whether a receipt was counted more than once. This small procedure separates mistakes in selecting entries from mistakes in adding them.

Specify the expected change before looking at the answer

Then choose one test from the matrix and write down the expected result before changing its input. If duplicating A’s lookup row, state that receipt D1 itself has not increased. If completing D3’s reference, state that the eligible amount remains unchanged while its unmatched classification changes. If reordering rows, neither the selected IDs nor the total should move. Specifying the expected scope of change in advance makes unintended effects easier to identify than inventing an explanation after seeing the answer.

Applying this method to actual data also requires checking whether a bank transaction ID can be reused or whether the same receipt appears on several statements. If the matching identifier is unreliable, the foundation of the check remains weak even when the total is right. Practical evidence may include bank statements, transaction status, records of customer obligations and reasons for lookup changes. An ordinary customer may not have access to all those records and cannot reconstruct the provider’s complete calculation from personal deposit and withdrawal history alone.

The outcome of this exercise is a more specific understanding of which explanation would advance the check, rather than a safety rating for a provider. Questions can address how unmatched receipts are retained, why each receipt is counted once and what changes in membership after a correction. No personal account number or identity document needs to be made public. Synthetic records and invented references are sufficient to explore the example. Inquiries about an actual service should use its official support channel and only the information needed for that inquiry.

14

Evidence of corrected transaction handling would change the assessment

The useful detail in any subsequent description of a repaired process would concern what was actually tested. Evidence that unmatched eligible receipts remain included, ambiguous lookup matches are resolved and corrections remain linked to their original transactions would advance the assessment. Customer names and account numbers need not be disclosed; anonymised test coverage and the treatment of failed cases can still explain part of the process. Renaming a procedure or changing its responsible department does not answer this calculation test.

An improving outcome would retain the repaired eligible receipts while continuing to exclude ineligible ones. If reruns with the same inputs agree and the same rules work across other deposit channels, concern about a narrowly targeted patch would recede. A report showing zero monetary difference is more informative when it also explains which transactions entered or left the population. The focus is whether the process works with corrections and exceptions, beyond a single day on which a test happened to pass.

Conversely, a corrected required amount without an explanation of which receipts were restored would leave the reconstruction incomplete. Holding more money could provide additional resources, yet a population error left in the calculation could reappear as funding needs change. More unmatched references on another channel or totals that move on rerunning identical inputs would also justify investigation. These are conditions for assessing future evidence, not assertions that such problems currently persist.

Use testable conditions to assess improvement or deterioration

Mixed outcomes are possible. Fewer omitted transactions alongside a growing exception backlog would imply that calculation quality and customer-service improvement are not the same thing. If aggregation is correct but extra checks take time, processing capacity and staffing need separate assessment. Conversely, more pending items could reflect the capture of records that were previously invisible, rather than deterioration. Changes in item counts need to be separated into changes in coverage and the ability to resolve the items.

Legal developments and evidence of operational calculation quality also answer different questions. Formal documents from the authority or court establish the stage of enforcement proceedings. Subsequent provider explanations or supervisory material would be needed to assess current safeguarding operations. Substituting a sanction amount for customer losses, or inferring a current balance shortfall solely from the disclosure of past breaches, would answer neither question accurately.

SG Group’s assessment centres on whether the conditions keeping receipts in the calculation can be tested before the final balance is reached. Retaining D3, counting D1 once and refusing to replace a missing receipt with D4 make three different failure modes visible in the fictional example. Readers can check whether the original transactions reproduce the same membership, rather than merely producing the same total. Evidence explaining those intermediate steps would also advance an assessment of actual operations more than general descriptions of safety or danger.