Banking AI | EU Regulatory Compliance

Use Fabric to understand a bank letter, compare an offer or plan your spending. Friends & Family covers five named people, each with their own Fabric access.

Compare a mortgage offer, make a budget or prepare for a bank appointment. Bring a little help to the money jobs on your list.

From an unclear letter to a useful question

Add your letter to Fabric. Check the explanation against the original, then take your questions to the bank.

An illustrative Fabric conversation. Your bank confirms the terms.

My bank sent this letter. What should I ask before I agree?

The letter describes a change to your loan rate. Here is what to check:

Your payment may rise when the fixed-rate period ends.

“What will I pay, including fees, and from which date?”

Check the explanation against your original letter.

Compare two loan or mortgage offers. Ask Fabric to lay out the rates, fees and conditions, and flag what needs checking.

Turn your statement into a budget. Pick out unfamiliar or repeated charges to check with your bank.

Make a short list of questions. Keep your letter and notes together for the call or appointment.

Your chats and files stay separate from the other people on your plan.

Fabric web and app for one named person.

Fabric web and app for five named people.

A reviewer asks how a lending decision was reached. Bring the source, policy version and human review into one case, ready for inspection.

Use the audit calendar to assign requests and find the evidence still missing. A shared view helps model risk, operations and compliance prepare together.

The case file connects the application, policy and review history. Follow the cited material before deciding whether a further review is needed.

Hand over the supporting documents, the applicable policy edition and the outstanding questions for the review meeting.

These example customer journeys show how a bank could turn a recorded decision into a written explanation and a documented human review.

Agree the operating model, access controls and retention policy before a proof of value. Check the required controls against your own obligations.

Walk us through a decision and the evidence your reviewers need. We can scope a proof of value around that case.

Agree the scope and acceptance criteria together.

Connect decision inputs, policy versions and reviewer actions to a replayable trace. Keep the integration boundary explicit.

The trace identifies the selected reasoning path, cited policy, reviewer and proof material. Inspect the layers on the sample decision below.

Pin the identifiers and policy version at the request boundary. Attach the decision and evidence to the response your application stores.

Review the rule set that was effective when the decision was made. Track later revisions separately from the historical record.

Check the recorded inputs, kernel and reference calculation. Retain the verification receipt with the run manifest.

Replay is bit-identical for the recorded inputs and pinned execution configuration. Retain the required artefacts and verify the chain offline.

Connect origination, decision processing and review through the event bus. Define ownership and retention at the handover points.

Review the request contract, retained artefacts and replay checks with us. Set acceptance criteria for your environment.

Load the decision and its pinned artefacts.

Compare the recorded decision and receipt.

A reviewer brings four documents into one case folder.

A tabbed case folder, a highlighted policy clause and a signed review slip.

A retained document moving through decision, record and replay.

The witness is sealed into a hash chain. Retained artefacts support replay and offline verification.

Decisions and traces use the bank’s event bus. Agree the processing location and network controls for the deployment.

The trace records the selected domain specialists and the constraints that fired.

Versioned policy nodes link the decision date to the applicable rule set.

Check a cited rule against the original policy before relying on the explanation.

Identify the processing location, access rights and relevant outsourcing obligations.

A transcript alone may not contain the inputs and execution artefacts needed for replay.

A card payment is held. The case opens with the transaction and the recorded check.

The customer asks for an explanation. The reviewer opens the recorded decision.

A reviewer checks the recorded inputs and documents the outcome.

The explanation cites the applicable rule and the factor behind the decision.

Give the customer a written reason they can take into a conversation.

Provide a route to ask a person to look again.

Specify where statements and identity documents are processed. Review the access and retention controls with the responsible team.

The supervisor can check the record against the retained artefacts.

Dweve as a managed service, via Fabric. Define the connection and processing boundary with the operating team.

Publish the trace to the event bus for audit storage and analytics. Define delivery and retention checks for both destinations.

Run on your own hardware and define the local storage and operational controls.

Use locally retained artefacts within an isolated network.

Dweve as a managed service, via Fabric. Agree the processing perimeter and operational responsibilities for your deployment.

Configure processing boundaries and access controls for the selected operating model.

Run the platform on your own servers, with your team responsible for the operating environment.

Operate within an isolated network with locally retained artefacts.

A transcript without execution artefacts

Which policy clause and application figure should the supervisor check next?

Open policy v6.2, clause 3.2 beside the dated application. The packet includes the supporting documents and a space for the reviewer’s follow-up.

The record supports the review. The responsible person decides whether the policy and outcome fit the case.

Evidence attached; judgement remains with the reviewer.

The explanation is hard to assess from a confidence number alone.

Inspect the retained execution alongside the original application.

Retain the evidence needed for your supervisory process.

Execution inside the agreed network boundary

Add the document you want to understand.

Take a clear question into the conversation.

See what a retained case adds to a transcript or score.

Inspect the recorded digests alongside the artefact list.

Agree connections and outbound controls.

Confirm the recipient can open the packet.

Assign unanswered questions before closing.

Compare a disputed figure with the original document before rerunning the case.

A correction does not guarantee approval

Confirm who may change the outcome and which cases need escalation.

Three everyday money jobs. Your bank still confirms the terms.

Chat, files, a knowledge base and saved workflows

A private workspace: your chats and files stay your own

Four layers stay together in one sealed decision record.

Case 4f9e stays pinned to policy edition v6.2 as other editions change.

A regulator names one declined credit decision and asks why. The clock starts. Nobody owns the answer yet.

The score lives in the credit engine, the rule in the policy wiki, the override in case notes, the context in an email thread.

A team rebuilds the decision and hopes the policy version they found is the one that was actually in force that day.

The decision has to come back the way it went out, with the rule, the version, and the customer factor in front of the inspector.

Debt-to-income ratio above the policy threshold on the application date. The full record is assembled and ready to replay for the inspector.

Why did we decline the revolving credit limit increase on case 4f9e?

The reviewer confirmed the decline and recorded a lower limit as available.

Reviewing officer, signed and timestamped

The policy version in force on the date of the application, not the one current today.

Applicant file and the exact document version the decision used.

Decisions trace back to the rules your bank authored, with the policy version pinned to the decision date.

The override is signed and dated, not a chat note

The reviewer sees the same evidence the system saw

Which rule fired, on which policy version, and who signed it off.

Whether the policy itself is the right policy for the case.

domain specialists selected: credit, fraud subset

A supervisory letter lands on Monday. By Friday your head of model risk has to show, for one declined credit decision, the rule that fired, the policy version in force, and the customer factor behind it. This is the week that evidence stops being scattered.