Laravel development for Edinburgh financial services

Edinburgh's financial firms do not have a scale problem. They have a correctness problem with a regulator attached.

The volumes are modest by consumer internet standards. What is demanding is that every figure has to be explainable, every access has to be accounted for, and the system has to behave correctly about things that happened years ago under rules that have since changed. A backend built on the assumption that the current configuration describes the world will be wrong about the past, quietly, and in writing.

An Edinburgh consent is a Laravel record with an expiry

The most common failure in Edinburgh fintech systems is also the most avoidable, and it comes from treating an access consent as a connection rather than as a dated permission.

Account access granted through an open banking interface expires - typically after ninety days - and the expiry is the design rather than a fault. A system that stores a token and assumes continuity finds out when a customer reports a balance that has not moved in a fortnight.

What works is modelling the consent explicitly: when it was granted, what it covers, when it lapses, and when it was last successfully used. Something watches the expiry and asks for re-authorisation before it matters. And during any gap the interface shows the time of the last successful refresh rather than presenting a stale figure as current, because an out-of-date number displayed confidently is worse than an honest absence.

Reconciliation is pennies, and pennies come from four places

Reconciliation sounds like arithmetic and behaves like forensics, because by the time it fails the cause is weeks upstream.

The causes repeat. A monetary value held as a floating point number somewhere in the chain. A percentage applied to each line and then summed, rather than applied to the sum, which differs by a penny per rounding. A currency conversion stored to two decimal places and then multiplied. A transaction timestamped in one timezone and grouped by day in another, so it lands in the wrong period and nothing balances for two days in a row.

None of these are difficult to prevent. All of them are expensive to find, which is why money and dates are the decisions you cannot undo is the first thing to settle on a payments project rather than something to revisit.

An Edinburgh firm's past has to stay true

Retention in financial services is measured in years, and that has a schema consequence most applications never face.

A transaction from 2022 was priced under 2022's fee schedule, under terms that have since been replaced, for a customer whose details have since changed. If the system recalculates it from today's configuration, it produces a number that is defensible to nobody.

So reference data is effective-dated rather than overwritten, and each transaction stores the values it was calculated with alongside a reference to the version it used. It is more storage and more discipline. It is also the difference between answering a regulator's question and reconstructing an answer from inference.

An Edinburgh regulatory return is a file with a schema

A return is not a report. A report is read by a person who can work out what was meant; a return is parsed by a machine that rejects it.

That changes where the work goes. The submission has a published schema, often versioned, with field-level rules that are stricter than anything the application enforces internally - a field that is optional in the database is mandatory in the return, a code list accepts eleven values and the application has been storing a twelfth. Validating against the schema before submission, rather than finding out at the regulator, is the whole game.

Rejections come back per record, not per file, which is the detail that catches teams out. Two thousand records go, nineteen come back refused, and the system has to know which nineteen, why, and what the corrected resubmission looks like under the regulator's rules - a full replacement, a delta, or a correction referencing the original submission identifier. Each of those is a different mechanism and the choice is not the developer's.

Underneath it, the return is generated from a frozen snapshot rather than from live tables, for the same reason the figures have to stay true. A return submitted in January and a return submitted in April covering the same period should differ only where a correction was made deliberately, and that is only achievable if the January numbers still exist as they were.

Laravel money arithmetic for an Edinburgh ledger

Money is not a decimal problem, it is an integer problem, and the applications that get into trouble are the ones that treat it as the first.

Amounts are stored in minor units as integers. No floating point reaches a balance, ever, because a tenth of a penny that cannot be represented exactly will eventually become a reconciliation that is out by one. A cast on the model keeps the rest of the code honest, so that an amount is a value object with a currency attached rather than a number that might be pounds and might be pence depending on which function last touched it.

Rounding is the second half and it has to be declared rather than inherited. A total of one hundred pounds split three ways is not three amounts of £33.33, because that loses a penny, and where the penny goes is a policy - largest remainder, first line, last line. Written down, it is a rule anybody can check. Left to the language, it is whatever the default happens to be.

Fees, tax and currency conversion are each separate entries rather than adjustments to an amount. A payment of £1,000 that arrives as £997.10 is a £1,000 entry and a £2.90 entry, not a £997.10 payment, because the latter cannot be reconciled against what the customer believes they sent. The same holds for an exchange rate - the rate, its source and its timestamp are stored with the entry, since a conversion nobody can reproduce is a number without provenance.

Commercially

Scope fixed in writing before work starts, priced per project. The country-level ground - UK data protection, consent, invoicing - is on the United Kingdom market page.

Invoiced by Codefacture Yazılım A.Ş. in Türkiye, in pounds by bank transfer, with no Turkish VAT under the export-of-services exemption. The entity name is what an outsourcing register needs, so it is worth having early.