Corrections and re-checks

Errors are fixed in place, with a date

An error is corrected on the page where it appeared, with a dated note saying what changed. We do not delete the page or silently swap a figure, because a reader who checked yesterday deserves to see that the ground moved. The note stays visible so the correction can be judged on its own.

This applies to figures, to descriptions of a broker's terms and to anything else the desk published. If a correction changes the sense of a ranking, the ranking is revisited on the same day the note is added.

Who Decides a Correction and the Time It Takes to Publish

The decision to correct rests with the person who maintains this page, and the test is whether the reported claim fails against the page's own definitions or the stated facts, not whether the report is popular. For a BTC/USD page, that means the maintainer checks the instrument definition (1 lot = 1 BTC, one pip = 1.0), the reference price, the leverage cap statement for the entity serving Kenya, and the exact regulator caveat before marking anything as an error. A reader report starts the check; it does not by itself decide the outcome. The maintainer publishes the entry with a date once the check is complete.

The time to publish depends on what must be verified, and the page does not promise a fixed number of hours. A wrong pip value can be checked against the instrument definition immediately. A disputed statement about the leverage cap requires confirming the cap that applies to the entity serving this country, which depends on the entity's current position rather than on a number the page can assume. A regulator caveat is checked against the exact wording that FxPro is licensed by the FCA (UK), CySEC and FSCA, not by the CMA of Kenya. The entry is dated when it publishes, and the log shows the interval between report and publication rather than hiding it.

The maintainer also decides which of the three marks applies, and that decision is recorded with the entry so a reader can see the reasoning. If a report concerns a margin example, the maintainer checks whether the example used the right lot size and the applicable cap, and marks an error only if the earlier figure was false on its date. If the earlier figure was true and the cap was later restated, the mark is update. The decision is not delegated to the reader who reported it, because a reader may be right that something looks wrong while wrong about which kind of change it is. The log shows the mark and the reason so the decision can be checked.

How a Correction Is Recorded and Dated on This Page

A correction is recorded as a dated entry that names the exact line changed, the old wording, the new wording, and the reason, and the date is the day the corrected version goes live, not the day the mistake was first noticed. On this page the date sits beside the corrected text and in the log entry, so a reader comparing two versions can see which one is later. The entry does not backdate to the original publication, because the original page was wrong on that date and the log should show that. If a reader reports a mistake on a Monday and the fix publishes on a Wednesday, the correction carries Wednesday's date and the log shows the gap.

The record keeps the old wording visible rather than replacing it silently, so the correction reads as a pair: what the page said and what it says now. For a BTC/USD page, that might mean showing that a margin example previously used a different lot size and now uses 0.10 lot with about $385.00 margin at the applicable leverage cap. The old figure is not deleted from the log; it is marked as superseded. This is how a reader can tell whether a page changed its meaning or only its phrasing, and it is why the log entry is longer than the corrected sentence itself.

Dating a correction also means stating what the correction depends on when the fact itself is conditional. The leverage cap that applies to the entity serving Kenya is a cap, not a setting to aim at, and a correction that touches leverage must say that the cap is the one for the entity serving this country rather than implying a single global number. If the cap statement was right but the worked example was wrong, the log records only the example as corrected and leaves the cap statement dated to its own last check. Each corrected fact carries its own date, so a page can have several correction dates without any of them being ambiguous.

A change is a re-check, not an error

A condition that has simply changed since we checked is a re-check, not an error. If a broker alters its leverage terms or its funding route after our reading date, the old page was accurate when written and is now out of date. That is a different thing from having published a wrong fact.

Re-checks are logged the same way, with the date the new reading was taken. A reader comparing a page to a broker's current site should look at the reading date first, then treat any difference as a reason to re-check rather than a reason to distrust the whole page.

The Three Change Types and How Each Is Marked on the Page

Every change on this page is marked as one of three types: error, update or clarification, and the mark appears both beside the changed text and in the log entry. An error mark means the earlier statement was false on its date. An update mark means the earlier statement was true on its date and has been superseded. A clarification mark means no factual claim changed, but wording that readers misread has been rewritten. The three marks are kept separate because they answer different reader questions: was I misled, is this still current, or did I misread it?

An error mark is the strongest and is used sparingly. It applies when a fixed claim fails against the page's own definitions or against the stated regulator caveat, such as a wrong pip value on a BTC/USD page where one pip is 1.0. An update mark applies when a figure that was correct for its date is replaced, such as a reference price moving to approximately 77000.0. A clarification mark applies when the sentence said something true but readers took a different meaning, and the fix is a rewording rather than a new fact. Each mark carries its own date, so a single paragraph can show an error corrected in one month and an update applied in another.

The marks are not interchangeable, and the page does not use a single generic 'edited' label. A generic label would hide the difference between a page that was wrong and a page that was merely current, and that difference is the whole point of the log. For the leverage discussion, a change to the statement that the applicable cap is the one for the entity serving this country would be an error if the earlier text named a different entity, and a clarification if the earlier text was correct but easily read as a global cap. The mark is chosen by what changed, not by how large the edit looks.

How to report a mistake

Report a mistake to editor@mombasatokenke.com and say which page and which sentence you mean. A link to the broker document that contradicts us is the most useful thing you can send, because it lets the desk check the point against the source rather than argue about it.

We do not promise a response time. What we do promise is that a reported error is checked against the broker's own documents and, if it holds, corrected with a dated note. If it does not hold, the page stays as it is.

What Qualifies as an Error Worth Logging on a BTC/USD Page

An error worth logging is a factual statement on the page that is wrong at the time it was published, not a later change in market conditions. For this BTC/USD page, that means a wrong instrument code, an incorrect pip value, a misstated lot size, a wrong reference price, or a regulatory statement that does not match the exact caveat for Kenya. A price that moves after publication is not an error; a page that says one pip equals 0.1 when the instrument definition says 1.0 is. The test is whether the page misinforms a reader about a verifiable fact at the moment of reading.

A typo that changes meaning counts, while a typo that does not change meaning is logged as a clarification rather than an error. If the page says 0.10 lot needs about $385.00 margin and a formatting slip prints $38.500, that is an error because the number a reader would act on has changed. If the same line reads 'about $385.00' and a later edit adds a comma for readability, no factual claim has changed. The distinction matters because the log should not fill with cosmetic edits, and readers should be able to trust that an entry marked as an error involved a wrong fact, not a wrong comma.

An error is also something a reader can point to without needing private data or a later event. Claims about FxPro's regulatory status in Kenya are checkable against the stated caveat that FxPro is licensed by the FCA (UK), CySEC and FSCA, not by the CMA of Kenya. A page that shortened that to 'regulated in Kenya' would be an error because the correction is visible from the caveat itself. By contrast, a statement that a spread 'depends on market conditions' is not an error even if a reader dislikes it, because it makes no fixed claim that can be shown false. The log is for fixed claims that fail, not for wording a reader would have phrased differently.

Why the Correction Log Stays Public and Visible

The log stays public because a reader cannot judge a page's reliability from its current text alone, and a visible history is the only way to see whether errors are acknowledged or buried. On a BTC/USD page that discusses margin, leverage and a regulator caveat, a reader is being asked to trust specific claims about costs and permissions. A public log lets that reader see that a wrong margin example was corrected with a date rather than quietly replaced. The log is not a marketing page; it is the record that makes the rest of the page checkable.

Keeping the log public also keeps the correction honest. When an entry must name the old wording, the new wording and the reason, the person making the change cannot substitute a vague 'updated for clarity' for a real fix. For this page, that means an entry about the Kenya regulator caveat must show that the caveat now reads that FxPro is licensed by the FCA (UK), CySEC and FSCA, not by the CMA of Kenya, rather than merely saying the caveat was improved. A public entry is a claim the reader can compare against the page, and that comparison is what stops the log from becoming a story the publisher tells about itself.

The log stays visible rather than archived because corrections matter most to the reader who is on the page now. A reader funding an account through M-Pesa and checking the leverage cap for the entity serving Kenya needs the correction beside the claim, not three clicks away in an archive. Visibility also means the log is not pruned when a correction looks unflattering. The page keeps the entry for the same reason it keeps the corrected text: a reader who saw the earlier version deserves to find out that it changed, and a reader who never saw it deserves to know the page has a habit of saying so.

Correction Versus Update: Different Claims, Different Log Entries

A correction fixes something that was wrong when published, while an update changes something that was right when published but is no longer current. On this page, correcting a misstated pip value from 0.1 to 1.0 is a correction because the instrument definition never changed. Updating a reference price from an older figure to approximately 77000.0 is an update because the old figure was accurate for its date and the market moved. The log marks them differently so a reader can tell whether the page misled them at the time or simply aged.

The practical difference shows up in what the entry says about the past. A correction entry states that the earlier page was in error and names the false claim. An update entry states that the earlier page was correct on its date and gives the new figure with its own date, without implying anyone was misled. For a BTC/USD page, a change to the stated lot size from something other than 1 BTC to 1 BTC would be a correction, because the instrument definition is fixed. A change to the worked margin example because the applicable leverage cap for the entity serving Kenya was restated would be an update, because the cap is a regulatory condition that can be restated.

Mixing the two would damage the log's usefulness. If every price refresh were logged as a correction, readers would see a page that appears to have been wrong dozens of times when it was only being kept current. If a genuine error were logged as an update, the log would hide the fact that a reader was given a false statement. The page therefore keeps two labels and applies them by asking one question: was the earlier statement false on its date, or true on its date and later superseded? The answer decides the label, and the label decides how the entry is worded.