Last updated 5 October 2026

Terms and conditions

These terms and conditions explain two different things, and the difference is the point of the document. The first is the use of the website at https://tervra.xyz. The second is the framework within which TERVRA LIMITED is willing to discuss engineering work, and the matters a later written agreement would have to settle before any such work is binding. Reading this page does not create a services contract. Sending the contact form does not create one. A telephone call does not create one. Only a written agreement that identifies the work does that, and this page does not pretend to be that agreement.

The company is TERVRA LIMITED, 108 Fonthill Road, London, N4 3HT, United Kingdom, reachable at general@tervra.xyz and on +44 7399 204815. The published practice is IT engineering and financial-technology software: custom software programming, computer systems design, cloud and web hosting infrastructure, data processing and analytics, financial technology solutions, credit intermediation systems, investment and brokerage software, high-load database management, enterprise API integration, cybersecurity and data protection measures, IT consulting and technical advisory, and system maintenance and monitoring. Those names are explained in the schedules at the end. They are service descriptions. They are not products you can buy by clicking.

This document is a draft for the website. It uses only the facts the site publishes. It does not add a company number, a list of directors, a set of standard prices, a service level, or a claim that TERVRA is authorised by the Financial Conduct Authority or any other regulator. Where a commercial question is open, the text says it is open. That is intentional. Inventing a price or a promise in a website draft would be less careful than leaving the question to a contract that names the system.

How to read these terms

Start with the idea that the website is a description and a contact channel. The terms of service are the shorter rules for that channel. These terms and conditions repeat some of those rules so that a reader who arrives here first is not sent away for the basic point, and then they go further into how a real engagement would have to be framed. If a sentence here conflicts with the privacy policy about personal data on the website, the privacy policy wins. If a sentence here conflicts with the cookie policy about cookies, the cookie policy wins. If a sentence here appears to create a services contract by itself, it does not. The formation clause below is the clause that decides that question.

Headings are for navigation. They do not change the meaning of the paragraphs under them. Words like “include” and “including” are not exhaustive. A reference to “writing” includes email. A reference to a statute includes that statute as amended. A reference to a person includes a body of people, corporate or not, unless the context is clearly about an individual. “You” means the person using the website or, where the context is a possible engagement, the organisation that would be the client. If you use the site for an organisation, you confirm that you are allowed to enquire on its behalf. If you are not, send the enquiry in your own name and say so.

The schedules are part of these terms. They describe what each published service name means and, just as importantly, what it does not mean unless a written agreement says otherwise. They are not statements of work. A statement of work would name a system, a boundary, and a way of judging the result. None of the schedules does that for a particular client, because no client engagement is published on the site.

The company the site actually describes

TERVRA LIMITED is presented as a UK company at the Fonthill Road address. The site does not publish a Companies House number, a VAT number, a D-U-N-S number, a list of directors, a founding year, an employee count, or a group structure. Those omissions are respected here. You should not infer them. If a notice, an invoice, or a contract needs a registration detail, that detail has to come from a source other than a guess, and it should be checked before it is written into a formal document. Until it is supplied in the relevant agreement, these terms identify the company by the name, address, email, telephone number, and website that are published.

The site does not publish business hours. A call or an email may not be answered immediately. Silence is not acceptance of an offer, and it is not a refusal that creates any liability. The practical routes are the email address, the telephone number, the postal address, and the form. The form’s behaviour is described in the privacy policy and below. It is an enquiry route with abuse controls. It is not a ticketing system with a published response time.

No office other than 108 Fonthill Road is stated. Do not address notices to a city or a building that is not on the site. The map on the contact page, if you choose to load it, is an illustration of that published address. It is not a representation that a particular room is open to visitors, and these terms do not create a right to turn up without an arrangement.

Definitions

“Website” means the pages served at https://tervra.xyz, including the index, the services page, the about page, the work page, the contact page, the thank-you page, the legal pages, and the scripts and images that belong to them. It does not mean a system TERVRA might later build for someone else, even if that system is described in general words on the services page.

“Enquiry” means a message sent through the contact form, an email to general@tervra.xyz, a letter to the published address, or a telephone call to the published number, in which a person asks a question or describes a possible piece of work. An enquiry is not an order.

“Written agreement” means a document, or a set of documents, in which TERVRA and a client identify each other, describe the work, and show that both sides have agreed. An email chain can be a written agreement if it actually contains that agreement and is not merely a discussion. A page of this website cannot be a written agreement with a client, because the client is not named on it.

“Client” means an organisation or person that has entered a written agreement with TERVRA for engineering work. A visitor to the website is not a client by visiting. A person who has sent an enquiry is not a client by sending it.

“Deliverable” means something a written agreement says TERVRA will produce: software, a design note, a configuration, a document, or another result named in that agreement. The website’s text and images are not deliverables. The scenarios on the work page are not deliverables.

“Client material” means information, access, data, credentials, or existing software that the client would have to provide before a piece of work could be done properly. Client material is defined in the written agreement if there is one. It is not defined by uploading a file to this website, because the website does not offer a file upload.

“Scope” means the boundary of a piece of work: what is included, what is excluded, and how the parties will know the work is done. Scope lives in a written agreement. The service names on the website are categories, not scopes.

“Personal data”, “controller”, and “processor” have the meanings they have in the UK General Data Protection Regulation and the Data Protection Act 2018. The privacy policy uses those words for the website. A future client agreement would have to use them again, carefully, for any system that processes personal data. These terms do not appoint TERVRA as a processor for data you have not yet been invited to send.

Status of the website

The website is published to explain the practice and to provide a way to make contact. Pages may be added, removed, or corrected. A description of a service is a description of a kind of engineering TERVRA offers to discuss. It is not a standing offer in the legal sense, and it is not an invitation to treat that becomes a contract when you fill in the form. Prices are not listed because prices are not a fact of the site. Availability of people is not listed because a headcount is not a fact of the site. Dates are not listed because a duration is not a fact of the site.

Illustrations on the work page are marked as an illustrative technical scenario, a representative workflow, or a capability study. They do not record a client, a metric, or a completion date. You must not rely on them as evidence of what a future system will cost or how fast it will run. You must not present them to a third party as TERVRA’s track record. TERVRA does not authorise that presentation.

Images are cinematic. They show equipment, rooms, and materials of the kinds that appear in engineering work. They are not a statement that a particular room is TERVRA’s office, a client’s office, or a data centre TERVRA operates. Alt text on the site describes what is in the frame. These terms adopt that restraint. Do not add a caption the site does not use.

No regulated financial activity is offered here

Several service names sit next to financial operations: financial technology solutions, credit intermediation systems, and investment and brokerage software. Those names refer to software and related engineering for firms that work in those areas. They do not refer to TERVRA lending money, intermediating credit as a lender or broker to the public, arranging investments, managing investments, or giving a personal recommendation. The website is not a financial promotion of an investment. It is not an invitation to apply for credit. It is not a quotation for a financial product, because no financial product is on sale.

If you are a firm that needs software around your own regulated activity, your permissions remain yours unless a written agreement, made with proper advice, says something else. These terms do not say something else. Building or discussing a platform does not move a regulatory permission from one company to another. If your question is whether a particular workflow needs a permission, you need advice from someone instructed to give it. The general caution on this page is not that advice, and it is not a substitute for it.

Nothing on the site is a statement of past performance of a fund, a portfolio, or a trading strategy. No such figures are published, and none should be inferred from the shape of a scenario. A scenario that says a record should stay intact is a statement about software design. It is not a statement about credit losses or investment returns.

Enquiries

You may enquire by the form, by email, by post, or by telephone. The form asks for a name, an email address, and a message. It asks you not to include passwords, card numbers, or special-category data. That request is part of these terms as well as part of the privacy policy. A message that ignores it may be deleted. TERVRA is not obliged to mine a message for a buried secret and then protect that secret as if it had been requested.

The form checks that the submission comes from the site, that the fields are usable, and that one network address is not posting a validated message too often. Those checks can reject a message. A rejection is an error on the page or a short retry page. It is not a decision about your business. If the server cannot hand the message to its mail transport, the site will say that delivery failed. You should then use the email address or the telephone number directly. Do not assume that a failed form has created a record that someone is working on.

An enquiry should describe the operation: what the system has to do, which existing systems it must respect, and whether personal data would be involved in outline. It should not attach a live customer file. TERVRA may ask for a clearer description before suggesting whether a written agreement is worth drafting. TERVRA may also decline to proceed, without giving a detailed reason, where the work is outside the published practice, where the enquiry is incomplete, or where the company simply does not take the work. There is no obligation to accept every enquiry. There is no waiting list with a published place in the queue.

How a services contract is formed

A services contract is formed only when TERVRA and the client have agreed in writing to a defined scope. The writing can be a single document or a short set of documents that refer to each other. It should be possible for a person who was not in the room to read it and see what was promised. A proposal that is marked as a draft is not agreement until it is accepted in writing. A proposal that asks for a signature is not agreement until it is signed or expressly accepted by an email that refers to it.

The website, these terms, a sales conversation, a demonstration of a scenario, and a reply that says a problem is understood are all capable of being useful. None of them is the contract. If there is a conflict between a casual email and a later document that both sides call the agreement, the later document should say which one wins, and if it does not, the document that is specifically about the scope prevails over a general brochure page. These terms always lose to a signed agreement on questions the signed agreement actually covers. These terms are not incorporated into a client contract unless that contract says they are. The default is that they are not, so that a project is governed by the document written for it rather than by a website page written for everyone.

Either side may walk away before the written agreement exists. Costs incurred in talking, visiting, or preparing a draft are borne by the side that incurred them unless a written agreement says otherwise. These terms do not create a restitution claim for a visitor who chose to prepare a long brief. They also do not entitle TERVRA to a fee for reading an enquiry.

What a written agreement needs to settle

Because the website refuses to invent commercial terms, it is fair to say what a real agreement would have to decide so that the parties are not surprised. A workable engineering agreement identifies the client and TERVRA, including the legal names. It describes the work in concrete language: the system, the users, the environments, and the boundary. It says what is out of scope, not only what is in it. It says what the client will provide, by when, and what happens if it is late. It says how a change is requested and how a change is accepted. It says how the result is judged, which is the acceptance question. It says what is paid, when, and what happens if an invoice is disputed. It says who owns the intellectual property in the result, and what licence the other side has if ownership does not pass. It says how confidential information is handled. It says how personal data is handled if any is processed. It says what the liability position is, within the limits the law allows the parties to set. It says how long the work runs and how it ends. It says which law governs it.

If a draft agreement is missing one of those subjects, the missing subject is not silently filled by this website. A missing price is not “a reasonable price” implied by a brochure. A missing liability cap is not a cap copied from this page, because this page does not set a project cap. A missing intellectual-property clause is not a transfer and is not a licence. The parties should fill the gap in writing or accept that the gap means the point is not yet agreed. Work should not start against a gap that matters. If work starts anyway, the parties take the risk that a court will have to decide a point they failed to decide, and these terms do not promise that the decision will match either side’s hopes.

Schedules at the end of this page list, for each published service, the kinds of facts that are especially easy to leave vague. They are a checklist of attention, not a set of default answers. Using a service name in an email (“we need API integration”) does not import the whole schedule as a specification. The schedule tells you what still has to be written down.

Changes after a contract exists

Once a written agreement exists, a change to the work should be written too. A change can be a new feature, a removed feature, a different interface, a different environment, or a different date. Spoken agreement in a meeting is easy to remember differently. The practical rule these terms recommend, and which a contract ought to adopt in its own words, is that a change is agreed by a short written note that says what is different and whether the difference affects price or time. These terms do not impose that rule on a contract that says something else. They do refuse to treat a website update as a change-control process for a client project.

A change in the law, or a change in a third party’s interface, can force a conversation. The website does not promise that TERVRA will absorb that cost inside an old price, because the website does not set the price. The contract should say who carries a change that neither side chose. If the contract is silent, the silence should be resolved by the parties or, if they cannot resolve it, by the dispute process in the contract, not by re-reading this page for a number that is not here.

What a client has to make possible

Engineering work depends on facts the client holds. A credit system cannot be shaped without knowing which decisions the firm makes and which system remains the system of record for a balance. An integration cannot be built without access to the interface, or at least to a specification and a test environment. A database cannot be sized from an adjective. “High load” on this website means concurrent operational use that has been described. It does not mean an unnamed benchmark. In a contract, the client should give the volumes, the peak patterns, and the failure that would be unacceptable, or should accept that the design will follow the description that was actually given.

Access should be the least access that lets the work be done. Credentials should not be sent through the public contact form. They should move through a channel the written agreement names. A client that shares production data when a synthetic sample would do takes a risk these terms have already warned against. TERVRA is entitled, in any future contract, to expect that the client has the right to share what it shares. These terms state that expectation as a condition of sensible discussion. They do not, by themselves, create a warranty from the visitor.

Decisions have to be made by someone who can make them. If a client’s security team, vendor, or regulator must approve a step, the contract should say so. The website does not know those internal rules and does not promise to discover them from a short form message.

Acceptance of work

Acceptance is the moment a client agrees that a deliverable matches the written scope, or the moment the contract says acceptance occurs because a review period passed without a stated defect. The website does not choose which of those mechanics a project will use. It does say that “it looks fine” in a meeting is a poor record. Defects should be described against the specification: what was promised, what happened, and how to see it. A wish for a new feature is not a defect. The schedules repeat that distinction where it is easy to blur, especially in consulting, where the deliverable is advice rather than a running system, and in maintenance, where the deliverable is care of a boundary rather than a new product.

Validation on the services page is described as checking the result against the agreed specification, including paths that carry real operational data where the client can supply them. That sentence is a description of a sensible stage. It is not a promise that every project includes a particular test suite, a particular environment, or a particular set of users. Those belong in the scope. If the client cannot supply the operational path, the contract should say what substitute is acceptable. These terms do not invent a substitute.

Charges

The website states no fees, no day rates, no packages, and no minimum spend. A figure you have seen elsewhere is not a figure of this site unless it is also written here, and it is not written here. Any charge exists only in a written agreement. An agreement should say the amount or the method of calculation, the currency, the timing of invoices, and whether expenses are included. It should say what happens if the client disputes an invoice: which part is still payable, and how quickly the dispute must be raised. These terms do not imply a statutory interest rate of TERVRA’s invention and do not set a credit period. If an agreement is silent, the parties have left a gap. The gap is not filled by a guess.

Work done without a written agreement is not ordered work. A client should not expect an invoice for a conversation, and TERVRA should not expect a fee for a conversation, unless a written agreement has already said that preparatory work is chargeable. These terms do not say that. If both sides want a paid discovery, the discovery needs its own short scope and its own price. Calling a meeting “discovery” does not create that scope.

Intellectual property in the website

TERVRA LIMITED retains all rights in the website’s text, structure, and images, except where a right belongs to someone else and is used under a licence that allows the use you see. You may use the site as the terms of service allow: read it, link to it, and keep a reasonable internal copy. You may not reproduce the scenarios as your own case studies, mirror the site, or remove legal notices. You may quote a short passage with an attribution to TERVRA LIMITED and a link, for commentary or for an internal note. A short quotation is not a licence to rebuild the page.

The name TERVRA LIMITED is the company’s name. Use it accurately. Do not register a confusingly similar name for an engineering service and claim the site encouraged you. Do not place the name next to a client logo the site does not show. There are no client logos on the site. That absence is part of the intellectual-property position as well as part of the factual position: there is no published endorsement to borrow.

Intellectual property in future deliverables

The website does not transfer intellectual property in software that has not been built, and it does not grant a licence in that software. Ownership and licence are commercial terms. They vary. A client that needs to own the result should say so in the agreement, and the agreement should say when ownership passes, usually on payment if that is the deal, and what pre-existing tools remain TERVRA’s. A client that needs only a licence should say what the licence covers: which entities, which territories, whether it is exclusive, whether it can be transferred, and whether it survives termination. These terms list the questions. They do not answer them with a default that would surprise one side.

Background material is the material a party already had, or the tools it uses across more than one engagement. A contract should distinguish background from the thing made for the client. If it does not, the parties risk arguing later about a library, a script, or a method. The website does not publish TERVRA’s internal tools and does not license them through this page. A scenario that describes an append-only history or an idempotent API is a design idea expressed in ordinary language. It is not a patent position, and it is not a claim that the idea is unique to TERVRA. It is also not a waiver of whatever rights do exist in a later implementation.

Third-party software and open-source software follow their own licences. A written agreement should say who chooses those components and who bears the licence obligations. The website does not attach a bill of materials, because there is no deliverable yet. A client should not assume that a future system is free of third-party terms, and should not assume that every component will be open source. The choice is part of the scope.

Confidentiality

The website is public. Do not send information you need to keep confidential until you have a written confidentiality arrangement, or until you have decided that the information is ordinary enough to live in a business inbox. These terms do not create a non-disclosure agreement. A footer that says a message is confidential does not, by itself, bind TERVRA to a special regime the parties have not agreed. TERVRA will treat an ordinary enquiry as business correspondence, which means it is not published on the site and it is not used as marketing, but it is read by the people who handle the mailbox and it may be stored as the privacy policy describes.

A proper confidentiality arrangement, if the parties want one, should say what is confidential, what is not, how long the duty lasts, and what the exceptions are. The usual exceptions are information that is already public, information that was already known without a duty, information that a third party gives without a breach, and information that must be disclosed because the law requires it. Those exceptions should be written in the arrangement rather than assumed from this page. This page records only that they are the sorts of exceptions a careful arrangement contains.

A client’s customer data is a poor candidate for an exploratory email. So is a security vulnerability in a live system, if the detail would let someone else exploit it. Describe the class of problem. Share the detail once the channel is agreed. TERVRA’s side of that expectation is not to ask for production secrets in the first reply when a description will do. Neither expectation is a warranty. Both are instructions for how to use the contact channel without turning it into a leak.

Personal data in a future project

The privacy policy governs personal data on the website. A system that processes personal data for a client is a different processing activity. These terms do not sign Article 28 terms, do not appoint TERVRA as processor or controller, and do not describe a retention schedule for a platform. If a project would process personal data, the written agreement should say who decides the purposes, who processes on whose behalf, what the categories and the data subjects are in outline, what security measures are in the scope, whether sub-processors are allowed, and how a breach that affects the client’s data is notified. Those clauses have to match the facts. A credit-application platform and a set of server logs do not raise the same questions, even though both can involve personal data.

International transfers of client data, if any, have to be handled under the law that applies to that processing. The website’s honesty about its own hosting, set out in the privacy policy, is not a template for a client’s production region. A contract should name the region if the region matters. If it does not name one, nobody should pretend this page named it.

Special-category data and criminal-offence data should be called out expressly if a system would touch them. The contact form asks you not to send them. A future scope should not sneak them in as “miscellaneous customer notes”. If they are truly required, the agreement should say why and on what basis. These terms do not supply that basis.

Security in a future project

Cybersecurity on the services page is a scoped set of measures, not a guarantee that a system cannot be breached. These terms repeat that limit because it is easy for a brochure to be misread as an insurance policy. A written agreement can include access control, encryption, logging, separation of environments, and a review. It can include a test only if the test is described. It does not include a certification the company has not claimed. The website claims no ISO certificate and no named government scheme. A contract must not recite one for convenience.

If a vulnerability is found in work TERVRA has agreed to maintain, the maintenance agreement should say how it is reported and what response is included. These terms do not set a number of hours. They do say that a public form is the wrong place for exploit detail. Use the channel the agreement names, or, if there is no agreement yet, describe the issue at general@tervra.xyz without a recipe for abuse.

Warranties the website does not give

The website is information published in good faith and corrected when an error is found. It is not warranted to be complete, and it is not warranted to stay unchanged. Service descriptions are general. They are not a warranty that a particular technique will suit a particular firm. Scenarios are not warranties of outcome. To the extent the law of England and Wales allows, implied warranties that are capable of being excluded for business use of a free website are excluded. Nothing here excludes a liability that cannot be excluded, including liability for fraud and for death or personal injury caused by negligence.

A written agreement can contain warranties about the work. Typical subjects are that the work will be done with reasonable care and skill, that it will match the specification, and that TERVRA has the right to license what it licenses. Those warranties should be written in the agreement, with the remedies the parties intend, such as re-performance. These terms do not imply them into a relationship that has not yet been agreed, and they do not forbid them in a relationship that is agreed. They keep the website from being the place where a warranty is accidentally made.

No warranty is given that a system will be fit for a regulated use. Fitness for a regulated use depends on the client’s permissions, its policies, and the specification. A vendor of software engineering cannot, on a public page, warrant a client’s compliance. These terms say that plainly so it is not left to a slogan about “bank-grade” work. The site does not use that slogan, and these terms do not introduce it.

Liability

Liability arising only from use of the website is dealt with in the terms of service and is repeated here so the position is in one place. Nothing excludes or limits liability for death or personal injury caused by negligence, for fraud or fraudulent misrepresentation, or for any other liability the law does not allow the parties to exclude or limit. Subject to that, TERVRA is not liable for business losses that arise only from reading the site, from relying on a scenario as if it were a case study, or from a form that fails and is reported as failed. The practical path when the form fails is to email or to telephone. Indirect and consequential loss arising only from website use is excluded so far as the law allows. Because the website is free, these terms do not publish a project-style cap dressed up as a website cap.

Liability arising from a services engagement exists only if a written agreement exists, and then it exists on the terms of that agreement. These terms do not insert a cap, a multiplier of fees, or an unlimited liability into a contract that has its own clause. They also do not insert a cap into a contract that forgot to write one. A forgotten cap is a problem for that contract’s proper law, not a problem solved by this page. Parties who care about the number should write the number. Parties who sign without a number have chosen, by omission, to leave the point to the law and to the rest of their document.

You are responsible for the consequences of sending data you were asked not to send, and for the consequences of presenting the website’s scenarios as client results. TERVRA is responsible for the content it actually publishes, within the limits above. Neither side is responsible, under these website terms, for the other’s decision to enter a bad commercial deal. The remedy for a bad deal is not to sign it, or to negotiate it, not to sue on a brochure.

No general indemnity from a page view

Some long terms contain a broad indemnity that makes a visitor pay for any claim connected with the site. These terms do not. A visitor who merely reads the pages has not agreed to indemnify TERVRA for the visitor’s existence. A visitor who misuses the site, for example by scraping it in breach of the terms of service or by pasting a scenario into a deck as a fake case study, is responsible for that misuse under ordinary law. A contractual indemnity for that misuse is not added here, because a website indemnity is easy to overdraw and hard to justify for a public information site. A services agreement can contain indemnities about intellectual property or about data the client had no right to share. Those indemnities belong in that agreement, written narrowly, and not in this page.

Availability, suspension, and ending website access

The website may be unavailable. No availability percentage is promised. TERVRA may suspend or withdraw the site, or any page, at any time. Suspension does not end a written services agreement. It also does not create one. If a form is unavailable, use email or telephone. TERVRA may refuse a submission that breaches these terms or that appears automated. A refusal is not defamation and is not a regulatory finding. It is a decision about a web form.

You may stop using the site at any time. Stopping does not delete an enquiry already sent. Deletion is a privacy request, handled as the privacy policy describes, not an automatic consequence of closing a browser tab.

Events outside reasonable control

Neither a visitor nor TERVRA is in breach of these website terms because a failure was caused by an event outside that person’s reasonable control, such as a widespread network failure, a failure of a mail transport the person does not operate, or a legal prohibition. This clause is about the website. It is not a force-majeure clause for a client project. A project clause should be written for the project, including what happens to dates and charges. These terms do not copy a project clause in miniature and hope it fits.

Notices

A notice about these terms, or about the website, may be sent by email to general@tervra.xyz or by post to TERVRA LIMITED, 108 Fonthill Road, London, N4 3HT, United Kingdom. A notice you ask TERVRA to treat as formal should say that it is a notice and should identify the page or the enquiry it concerns. TERVRA may give you a notice about the website by email if you have provided an address, or by a clear change to the relevant page where the notice is about the terms themselves. Postal notice is treated as given two business days after posting within the United Kingdom, if it was properly addressed. Email notice is treated as given on the next business day after it was sent, if no bounce was received. These timings are for website notices. A services agreement should set its own notice clause, especially if invoices and breach notices must go to a particular person.

A telephone call can start a conversation. It is a poor record of a notice. Follow a call with an email if the point matters. The site does not publish a list of named individuals, so do not insist on serving a notice on a director who is not identified here. Serve it on the company at the published address.

Complaints about the website

If a page is wrong, write to general@tervra.xyz with the address of the page and the correction you think is needed. Factual corrections about the company should match documents you can point to. TERVRA will correct a clear error. A disagreement about emphasis is not always an error. A complaint that the site refuses to show invented metrics will not be resolved by adding metrics. The work page is deliberately without them.

A complaint about personal data follows the privacy policy, including the right to complain to the Information Commissioner’s Office. A complaint about a services engagement follows the written agreement for that engagement, if one exists. These terms do not set up an ombudsman scheme, and they do not claim membership of one.

Assignment and other parties

You may not assign your permission to use the website. The permission is personal to the reader. TERVRA may use contractors to host the site and to handle mail. That ordinary operation is not an assignment of a services contract, because the website relationship is not a services contract. A services agreement should say whether either side may assign it, and whether subcontracting of the engineering work is allowed. These terms do not pre-approve subcontracting of client work and do not forbid it. They leave it to the agreement, which should also say that subcontracting does not remove TERVRA’s responsibility to the client for the work TERVRA agreed to do, if that is the deal the parties want. If they want a different deal, they should write it.

The Contracts (Rights of Third Parties) Act 1999 is excluded from these website terms. A person who is not a party does not acquire a right to enforce them, except that a party’s permitted successor may enforce them if an assignment were ever relevant, and except that a right which already exists apart from that Act is untouched. A services agreement should include its own third-party clause. Excluding the Act here does not exclude it there.

Severance, waiver, and the whole website agreement

If a court holds that a clause of these terms cannot be enforced, the clause is modified to the minimum extent needed to make it enforceable, or it is removed if modification would change its meaning. The rest of the terms stay. A failure or delay in enforcing a term is not a waiver. A waiver of one breach is not a waiver of a later breach. These terms, the terms of service, the privacy policy, and the cookie policy are the whole agreement about the website. They replace earlier website terms on the same subject from the date at the top. They do not replace a signed services agreement. They do not record oral promises about a project. If you think a promise about a project was made, put it in the draft agreement or accept that it is not yet a term.

Law and jurisdiction

These terms and conditions are governed by the law of England and Wales. The courts of England and Wales have exclusive jurisdiction over disputes about the website and about these terms, subject to any mandatory rule that allows a consumer to sue or be sued elsewhere. The site is written for organisations. If you use it as a consumer, you keep the mandatory protections the law gives you, and nothing here is an attempt to make you waive them. A services agreement should choose its own law and courts. The natural connection of the company as published is England and Wales, but a cross-border project may need a different clause. These terms do not force that project into a clause the parties have not signed.

A dispute about the website should be raised in writing before proceedings, except where urgent injunctive relief is genuinely needed, for example to stop a misuse of the content that will not wait. The invitation to write first is a practical step. It is not a mediation scheme with a nominated provider, because no provider is named on the site. Do not treat silence after a letter as consent to a forum the letter invented.

Schedules: what each service name means

The schedules use the service names published on the site. Each schedule says what the name refers to, what a written agreement would still have to define, and what is outside the name unless the agreement pulls it in. The schedules are careful not to state a fee, a duration, a certification, or a client result. Where a schedule says “unless the agreement says so”, the silence of the agreement means the item is out, not in. That reading protects both sides from a surprise inclusion.

Schedule 1. Custom software programming

Custom software programming means an application, a service, or a tool written for an operational job the client can describe. The job might be internal, it might sit in front of the client’s own users, or it might be called by other systems. The website does not publish a language, a framework, or a cloud vendor as a standing choice. A written agreement should name the behaviour to be built, the environment it must run in, and the tests or checks that count as enough. It should also name what will be handed over: source code, build instructions, credentials, and documentation, to the extent those things are part of the deal.

Unless the agreement says so, the service does not include a redesign after acceptance, a commitment to a particular open-source licence, a mobile application as well as a server application, or content writing for a marketing site. A bug that departs from the specification is a defect question. A new screen that nobody specified is a change. The agreement should keep those categories apart. Data migration from an old tool is a separate piece of work unless the scope lists the source, the fields, and the tolerance for rejects.

The client should provide the rules the software must follow and a person who can answer questions while the work is underway. TERVRA should not have to invent a business rule and then be told the invention was wrong. If the rules are unstable, the agreement should say that discovery is part of the scope, with a boundary on how long discovery lasts. These terms do not set that boundary in days.

Acceptance for programming work should be tied to agreed scenarios, not to a general sense that the software feels finished. Performance targets, if they matter, need numbers the client is willing to stand behind: what load, on what data, with what response. A sentence on the website about careful engineering is not a performance target. Intellectual property in the resulting code is left entirely to the agreement, as the deliverable-IP clause already says.

Schedule 2. Computer systems design

Computer systems design is the work of deciding the parts of a system before, or instead of, writing all of the code. It covers components, the data each component owns, the calls between them, and the failures an operator must be able to see. A design can be a document, a set of diagrams, or a short note that rules a bad approach out. The deliverable should be named. “A design” is not a named deliverable until the agreement says how long it is and what decisions it must record.

Unless the agreement says so, design work does not include building the system, running a procurement, selecting a vendor on the client’s behalf, or attending the client’s board. It does not include a promise that the design can be built for a cost the website has not stated. A design that reveals a larger problem than the client hoped is still a design. The remedy is to decide what to do next, not to treat the unwelcome fact as a defect in the paper.

The client should say which systems already exist and which of them must not be replaced. A design that ignores a system of record will not survive contact with the operation. The client should also say which constraints are real: a region, a vendor that cannot be used, a security rule, a deadline imposed by someone else. Constraints that appear after the design is accepted are changes.

Design materials are easy to forward. The agreement should say whether the client may share them with a bidder, a regulator, or an affiliate. These terms do not grant that sharing right. They also do not stop the client from using ideas that are ordinary engineering knowledge. The line between ordinary knowledge and the document itself should be drawn in the agreement if the parties care about it.

Schedule 3. Cloud and web hosting infrastructure

Cloud and web hosting infrastructure means the environment that runs software or a site: compute, storage, network paths, certificates, deployment, and the accounts that control them. The website distinguishes hosting a site from infrastructure for an operational platform. An agreement must say which of those it is buying. It must also say who owns the cloud account. An account in the client’s name is a different risk from an account in TERVRA’s name, and the website does not choose between them.

Unless the agreement says so, infrastructure work does not include an unlimited availability target, a disaster-recovery drill, a multi-region design, a penetration test, or the cost of the cloud provider’s own invoices. Those invoices are often the client’s, and the agreement should say so rather than leave a surprise. Backups are included only if the scope says what is backed up, how often, where the copies live, and whether a restore has to be demonstrated. A backup that has never been restored should be described as untested if that is the truth of the engagement.

The client should provide the domain names it controls, the legal right to use the software that will be installed, and a decision about production data. Putting production data into a casual environment is a data-protection decision, not a hosting convenience. TERVRA should be told which environment is allowed to hold which data. These terms do not authorise production data in a test account.

Handover of infrastructure includes the knowledge required to operate what was built, to the extent the agreement lists it: repositories, pipelines, and the location of secrets. Secrets should be rotated when people change. The website does not set a rotation calendar. Maintenance of the environment after handover is Schedule 12, not an automatic tail on Schedule 3.

Schedule 4. Data processing and analytics

Data processing means taking operational records and producing a version that software or people can use. Analytics means reporting on that version. The services page separates the two so that a report does not become the place where the business records the fact. An agreement should keep the same separation. It should name the sources, the checks that reject a bad record, the store that holds the processed view, and who may read it. It should say whether late or corrected source data must flow through again.

Unless the agreement says so, this service does not include a decision about what the numbers mean commercially, a model that grants credit, a forecast that a regulator will accept, or a dashboard for every team in the client. It does not include buying data from a broker. It does not include cleaning a decade of archives if the scope named a year. Rejected records should be visible. Silently dropping them is a defect if the scope said they would be kept aside. If the scope said nothing, the parties should not argue from this page that one behaviour was promised.

The client remains responsible for decisions it takes from a report. TERVRA’s work, where contracted, is to build the pipeline and the report that were specified, with reasonable care. A wrong business decision made from a correct report is not a defect in the pipeline. A report that computes a specified field wrongly is a defect. The agreement should give an example of each if the domain is easy to confuse, which financial operations often are.

Personal data inside a pipeline brings Schedule 4 together with the data-protection clause. Categories, purposes, and retention of the processed view belong in the agreement. The website’s own retention approach for enquiry emails is irrelevant to a client warehouse and must not be copied across by habit.

Schedule 5. Financial technology solutions

Financial technology solutions, in TERVRA’s published practice, are software for firms that run financial or investment operations: workflow, an operational record of what the software did, permissions, audit history, and connections to systems the firm already uses. The name does not mean a consumer finance product, a payment service, or an investment product offered by TERVRA. An agreement that uses this name should say which workflow is in scope and which regulated activity, if any, remains entirely the client’s.

Unless the agreement says so, the service does not include a regulatory application, a compliance opinion, a consumer-duty assessment, or a licence to use a payment scheme. It does not include holding client money. It does not include a promise that the software makes the client authorised. Those are legal and regulatory tasks for people instructed to do them. TERVRA can build the system those people describe. The description has to be in the scope, not assumed from the word FinTech.

Audit history is a common requirement and an easy place to be vague. The agreement should say which events are recorded, whether the record can be altered, who can read it, and how long it is kept. “A full audit trail” is not a specification. The credit scenario on the work page is an illustration of one shape, an append-only history beside a named policy version. It is not the default scope of every FinTech engagement, and it is not a client result.

Acceptance should include a walk through the permissions model with the client’s own administrator, if an administrator is in scope. A system that only the original author can operate is unfinished if the scope promised a handover. If the scope did not promise a handover to a named role, the client should not discover that gap at the end and call it a defect without looking at the paper.

Schedule 6. Credit intermediation systems

Credit intermediation systems are software around an application, a decision, and the record of both. Intake stores what was submitted. Decisioning applies rules the client can name and version. History shows what changed. Downstream servicing or core systems are integrated rather than replaced, unless the scope says they are being replaced. TERVRA does not grant credit and does not become the lender because it wrote the workflow.

Unless the agreement says so, the service does not include credit scoring models trained on the client’s historic book, a bureau integration, a collections dialler, or a customer-facing marketing site. Each of those can be added by being written into the scope, with the third-party contract and the data-protection role made explicit. A rules engine that the client’s staff can edit is a different product from a rules engine that only a developer can edit. The agreement should say which one is wanted. “Configurable” is not enough.

The client must provide the decision policy and the versioning rule. If the policy is “whatever the underwriter did last time”, the software cannot be judged. The client must also say which system remains the system of record for the balance or the account. The website’s scenario assumes that core systems often stay. That assumption is a caution, not a requirement that every project leave the core untouched. The scope decides.

Adverse action and explanation duties, where the law imposes them on a lender, stay with the party the law names. The software can store a reason code if the scope includes a reason code. It cannot, by existing, discharge the lender’s duty. These terms refuse any reading on which delivery of a credit workflow is legal advice about that duty.

Schedule 7. Investment and brokerage software

Investment and brokerage software means operational software for those workflows: handling of orders and positions as software behaviour, reference data, allocations, and the screens or interfaces an operations team uses. It is not a portfolio managed by TERVRA, not a fund, not a venue, and not a personal recommendation. An agreement should describe the workflow in the client’s language and then translate it into behaviour. It should say which books, which instruments, and which entities are in scope, and which are deliberately left out.

Unless the agreement says so, the service does not include best-execution monitoring as a regulatory opinion, market-data licences, a connection to a particular venue, or a client-money reconciliation signed by an auditor. Market data is often the client’s licence to buy. The agreement should say who pays the licence and who is allowed to display the data. Building a screen that would breach the client’s market-data contract is not a success. The client has to state the display rules it already lives under.

The representative workflow on the work page, which separates a landing store from a published view, is an illustration. It becomes part of a project only if the scope adopts it. A different firm may need a different split. Volumes, correction cycles, and the definition of a business day should be written down if the pipeline must meet them. The website states none of those numbers.

Acceptance for this kind of software should use fixtures the client recognises: a known corporate action, a known allocation, a known break. Invented fixtures that do not resemble the operation will pass tests and fail in life. The client’s duty to provide realistic fixtures is part of making the work possible, as the client-duties clause describes. These terms do not supply sample market data.

Schedule 8. High-load database management

High-load database management means design and operation of a database for concurrent use that the client has described. It includes schema, indexing, backup and restore as specified, and the administration the agreement assigns either to TERVRA or to the client. It does not include a published benchmark, because the website contains none. “High load” without a description is not a contractual load.

Unless the agreement says so, the service does not include a particular database product, a particular clustering technology, a 24-hour on-call rota, or a capacity that grows without a change. Product choice should be written down, including who holds the licence. Clustering and failover should be written down if they are required, including how a failover is tested. A diagram that shows two nodes is not a test. The agreement should say whether a test is in scope.

The client should say which facts must never be double-written and which reports the software actually runs. Indexing follows those queries. An index for a report nobody runs is not a requirement, and a missing index for a report the scope named is a defect. Retention of rows is a data-protection and a cost question. The agreement should state it. The website’s refusal to publish one retention period for enquiry emails is not a suggestion that client databases should keep everything forever.

Operational administration after go-live is maintenance if the maintenance schedule is agreed. It is not an implied retainer. Credentials for production databases should be handled as secrets. They must not be pasted into the public form. A restore test that uses production data needs an explicit decision. These terms do not make that decision on the client’s behalf.

Schedule 9. Enterprise API integration

Enterprise API integration means connecting systems that already exist by a defined interface. The agreement should state the fields, the errors, the idempotency of a retry, the authentication method, and what the integration does when the other side is down. It should list the systems. “The client’s estate” is not a list. Each system that is in scope should be named, and each system that is out of scope should be named where confusion is likely.

Unless the agreement says so, integration does not include rewriting the remote system, buying a licence for it, or guaranteeing the remote vendor’s uptime. If the remote interface changes, the response is a change to the agreement, not an open obligation. The client should give timely notice of vendor changes it knows about. TERVRA cannot watch every vendor’s release notes unless watching them is a monitored task in Schedule 12.

Idempotency matters when a retry could create a second payment instruction, a second order, or a second decision. The scope should say which calls must be safe to repeat. A capability study on the work page discusses a single writer for each aggregate. That study is not the default architecture of every integration. It is a prompt to decide. The agreement should record the decision.

Interfaces that carry personal data need the data-protection clause as well as the field list. The minimum data that makes the other system work should be preferred to a full dump. These terms do not authorise a full dump. Authentication secrets follow the same rule as database credentials: a named channel, not the public form. Acceptance is a run against the test environment the scope identified, with the error cases the scope identified, not only the happy path.

Schedule 10. Cybersecurity and data protection

This schedule covers engineering measures inside a scope: access control, secrets, encryption in transit and at rest where agreed, logging, and separation of environments. It also covers help so that a system collects what it needs and keeps it where the agreement says. It is not a guarantee that a breach will not happen. Any agreement that uses this service name should repeat that limit in its own warranty clause so that a later reader does not have to find it on the website.

Unless the agreement says so, the service does not include a certification audit, a penetration test, a 24-hour monitoring room, incident response for the client’s whole enterprise, or insurance. A test that is wanted must name the target, the window, the rules of engagement, and whether production is in bounds. Testing production without written rules is not a service TERVRA offers through this page. Findings are the deliverable of a review. A finding is not a failure of the review. Remediation of a finding is in scope only if the agreement says the finding will be fixed rather than reported.

The client should name the data and the systems that are in the review. A review of “everything” is not a scope. The client should also say which control framework, if any, it wants the language of the report to follow. These terms do not adopt a framework by default, because the website claims none. If the client’s auditor needs evidence, the agreement should say what evidence will be produced. An engineer’s notebook is not an audit pack unless the scope says the pack will be written.

Breach notification between TERVRA and the client, if TERVRA is processing personal data, belongs in the data-protection clause with a method and a timing the parties choose. These terms do not invent a 72-hour promise from TERVRA to the client, because that statutory timing, where it applies, is a controller’s timing toward a regulator and the facts of the project decide who the controller is. Copying the number into a website schedule would blur that distinction. The agreement can set a practical notice period between the parties. This page only insists that the period be written if the parties need one.

Schedule 11. IT consulting and technical advisory

Consulting is advice on software, data, infrastructure, and the shape of a system. The output is the written advice that was asked for: a review, a comparison, a recommendation, or a note that says what not to build. An agreement should say the question, the materials the client will provide, and the form of the answer. Advice on the website is general. Advice under this schedule becomes specific only inside that agreement. It is not investment advice and not legal advice, even when the system sits next to a financial workflow.

Unless the agreement says so, consulting does not include building the system, negotiating with a vendor, giving evidence in a hearing, or remaining on call after the note is delivered. A recommendation that the client dislikes is not a defect if it answers the question that was asked and shows its reasoning. A note that ignores a material fact the client actually provided can be a defect. A note that ignores a fact the client withheld cannot. The client’s duty to provide the materials is therefore part of the quality of the advice.

Consulting does not oblige either side to continue into a build. A build is a new scope under Schedule 1 or whichever other schedule fits. These terms do not create an exclusivity arrangement. The client may take the advice and have someone else build. The agreement should say whether the advice may be relied on by a third party such as an investor or a buyer. The default under these terms is that it may not, because third-party reliance is excluded above and should be granted only expressly, with a named person and a named purpose.

Fees for consulting, as for every other schedule, exist only in the agreement. A workshop that was not priced is a conversation, not a purchased report. If the parties want notes of a workshop to count as the deliverable, the agreement should say that the notes are the deliverable and when they are due. These terms do not turn every meeting into a report.

Schedule 12. System maintenance and monitoring

Maintenance is care of a system already in use: updates that were agreed, fixes for faults inside the maintained boundary, and small operational changes the arrangement names. Monitoring is watching the signals that were chosen and following the response path when those signals fire. An agreement should draw the boundary in a picture or a list: which repositories, which environments, which integrations, which hours. A boundary that says “the platform” will be argued the first time something breaks at the edge.

Unless the agreement says so, maintenance does not include a stated response time, a named severity ladder, cover at night, cover on public holidays, or a security operations centre. The website refuses to print those numbers. If the client needs them, they must be written, including what “response” means: a human reply, a mitigation, or a fix. Those are different promises. Monitoring does not include watching systems outside the boundary, and it does not include a warranty that an alert will fire for every failure mode. The signals are the ones that were chosen. Adding a signal is a change.

Faults caused by a change the client or a third party made outside the arrangement are outside the fix obligation until the arrangement is varied. The agreement should say how that situation is recognised and whether investigation of the unknown is chargeable. These terms recommend that the agreement say it. They do not impose a free investigation duty of their own. Backups and restores during maintenance follow whatever Schedule 3 or Schedule 8 already specified, or follow a fresh clause if those schedules were never bought.

Ending maintenance should be possible on written notice of a length the agreement sets. These terms do not set the length. On ending, credentials should be rotated and access removed. Knowledge that was supposed to transfer should be listed, or the client should accept that it lives in the repository and the runbooks that existed on the end date. A maintenance arrangement is not a permanent employment of a company, and the website does not offer one.

If a schedule and a clause seem to disagree

The clauses in the body of these terms describe the website and the way any future agreement has to be formed. The schedules describe the published service names. If a schedule appears to promise a result that the body says only a written agreement can promise, the body wins. The schedule is a glossary and a warning list, not a second contract hiding at the bottom of the page. If two schedules could both describe one piece of work, the written agreement should pick the one that fits or say that both apply and where the join is. Overlap between integration and databases, or between FinTech and credit systems, is normal. Overlap is not a reason to assume every neighbouring schedule has been bought.

A reader who only needs the website can stop at the liability, notices, and law clauses and use the shorter terms of service for day-to-day browsing. A reader who is about to send a serious enquiry should look at the schedule that matches the work and notice what it says is still undecided. Sending the form after reading a schedule is still only an enquiry. The schedule does not become attached to that message as a specification. If you want a schedule heading to be the title of a draft scope, say so in the message, and expect the draft to fill the gaps the schedule pointed out.

Closing

The schedules end where the published service list ends. If you need work that does not fit a schedule, say so in the enquiry and do not force the work into the nearest name. A name is a convenience. The scope is the agreement. TERVRA LIMITED can be reached at general@tervra.xyz, on +44 7399 204815, and at 108 Fonthill Road, London, N4 3HT, United Kingdom. Use the contact page if you want the form. Use this document as a map of what still has to be decided, not as a decision already made.