Payment service
Documents for a bank review
BriefTo pass a review by the bank. The user terms, the personal data documentation and the anti money laundering procedures had to be brought into a state where they agree with one another and match how the service actually works.
WorkAudited the three sets of documents and supplied what was missing: internal control procedures (customer identification, risk assessment, detection of suspicious transactions), a risk register and the public policies. The discrepancies found were set out as a list with priorities for correction.
OutcomeThe bank compliance review was passed. The public documents and the internal procedures describe the same rules.
Investment project
Independent review of a transaction
BriefThe project approached launch with a transaction pack prepared by other advisers. An independent opinion was required on whether to rebuild the pack or repair the existing one.
WorkReviewed the entire pack and produced a memorandum with ten findings, ranked by materiality and by likelihood of occurring. Set out the reasons against a rebuild: the findings were capable of correction within the existing structure.
OutcomeThe pack was not rebuilt. The findings were closed by amendments to the documents themselves, producing a consolidated edition covering the full life cycle of the transaction. Two conditions were identified separately, on which it is the structure of the instrument that would need revisiting, not the wording.
Technology company
Development contract
BriefThe model of the project changed during the work: the contractor began producing the prototypes itself, while the bilingual contract had been drafted for the earlier arrangement. Who produces the prototypes determines both what the deliverable consists of and in whom the rights in it arise.
WorkBrought the contract into line with the actual model of work: clarified what is delivered, how it is accepted and when exclusive rights pass, and removed duplicate annexes.
OutcomeRights in the results are fixed in the wording itself rather than left to the default rules: those allocate rights differently depending on the type of result, and cannot be relied on here. Acceptance and the transfer of rights are evidenced by a single document.
Buyer of software
Legal purity of an acquired asset
BriefA company was acquiring a software product from an outside supplier. It had to be established that the exclusive rights had in fact passed to the acquirer, and whether the actual composition of the product created any encumbrance on its further use.
WorkTraced the chain of title in four steps, from developer to acquirer, against the underlying documents. Audited the open source components in the build: 928 items, each checked against its licence terms and against the intended model of use. Components carrying copyleft obligations were addressed in a separate memorandum.
OutcomeBefore closing, the acquirer knew what it was buying: whether the chain of title held, and which components constrain the intended model of use. The encumbrances found were set out with remediation scenarios.
Digital product
Personal data
BriefThe service was collecting user data and connecting external analytics tools without the documents describing this.
WorkDetermined the protection level, prepared a threat model and assembled the operator's documentation: the policy, consent forms, processing instructions and the procedure for handling data subject requests. Cross border transfers and the requirement to record the data of Russian users in databases located in Russia were addressed in a separate section.
OutcomeThe published documents describe what the service actually does. An inspection looks not only at whether a policy exists, but at whether its wording matches how the system actually behaves.
Business and advisers
Second legal opinion
BriefA business had received research from advisers on which a decision was to be based, and asked for it to be checked before the decision was taken.
WorkChecked the conclusions against primary sources: the legislation, official guidance and the published positions of regulators. Identified errors of two kinds: citations to provisions that do not say what they are cited for, and conclusions that do not follow from the provisions relied on.
OutcomeA list of findings, each with reasoning and a suggested correction. The decision was taken on verified conclusions.
Cross border project
Allocation of risk in a bilingual contract
BriefPayments under the project ran in foreign currency through banks in third countries, while the counterparty's draft placed the resulting risks entirely on the contractor.
WorkPrepared nine compromise amendments in parallel language versions: correspondent bank blocking, escrow against sanctions blocking the payments, a cap on liability for infringement of third party rights, change of control, and exclusion of the Vienna Convention.
OutcomeThe allocation of risk is no longer one sided. Each amendment is drafted as a compromise rather than a demand, so that it can be accepted without escalating the negotiation.
Intangible asset
Bringing software onto the balance sheet
BriefA company had acquired a software product and was recognising it as an intangible asset. It had to be determined whether the contract concluded provided a basis for this, at what amount and over what period the asset should be recognised, and the reasoning had to be prepared in advance rather than at the point of an inspection.
WorkBegan with the characterisation of the contract. An assignment of the exclusive right and a grant of a right of use can both give rise to an intangible asset, but the object recognised, its useful life and the tax treatment differ. Checked that the recognition conditions were met, established the initial carrying amount and the useful life, and drew the line between adaptation costs and modernisation costs. Ran the same transaction in parallel against the international standards, including the impairment test, and set the risks out in a matrix.
OutcomeThe company obtained a basis for recognising the asset and an understanding of what that basis rests on. The documents it was missing were listed separately: the business purpose rationale, the commissioning order and the technical inventory. Each is needed not for its own sake but against a question being raised about the transaction.
Joint venture
Corporate structure and a contribution of know how
BriefThe parties were setting up a joint venture to bring a development to market and had to choose between three forms, ranging from a separate company to a licensing model with no legal entity at all. The client was entering the project as a minority participant.
WorkWorked through the three scenarios and compared them by their consequences for control, for the allocation of rights in the results and for exit. Reviewed the charter for risks to a minority holder, prepared the shareholders agreement and the mechanics of contributing know how. Separately assembled the set of internal acts on works made for hire: the dispute is rarely about the employer right as such, but about whether what was created fell within the duties of the employee.
OutcomeThe form chosen is justified by its consequences rather than by convenience of paperwork. Rights in the results are secured at two levels at once: in the charter and the shareholders agreement, and in the internal documents of the company.
Trade secret
Protecting development work inside the company
BriefThe company was protecting its source code and know how, but its trade secret regime had not been established in the sense the law requires: some of the mandatory measures were missing and the rest took no account of how development actually worked.
WorkPrepared the trade secret and know how regulations for the actual infrastructure: repositories, cloud services, marking of source code, access logs as evidence. Set out the obligations of counterparties and the duties of employees after they leave. A separate section introduced a ban on passing information to external artificial intelligence services, distinguishing cloud models from those deployed inside the perimeter.
OutcomeThe regime became enforceable: it describes what staff actually do every day and leaves traces that can be relied on as proof.
Software licensing
Royalty tied to the result the licensee achieves
BriefA rights holder was giving a financial institution access to its software. The consideration had to be built so that it grew with the licensee income yet did not fall to nothing in periods when there was none.
WorkBuilt the consideration in two parts: a lump sum on signing and periodic payments calculated as a share of the success fee the licensee earns, with a floor for each reporting period. Provided a recalculation mechanism running both ways for cases where the licensee fee is adjusted retrospectively. Limited the scope of the licence by method of use and by territory, while preserving the right holder freedom to license the software to others. Tied the tax treatment to the moment the software enters the Russian software registry.
OutcomeThe rights holder shares in the result the licensee achieves rather than only charging for access, and is protected by the floor. Retrospective adjustments on the licensee side do not create a dispute: the recalculation is described in advance.
Contractor agreement
Risk of reclassification as employment
BriefThe company engaged an individual under a civil law contract for development work and asked for the closing documents to be checked before payment.
WorkThe reporting form was built around time spent. In a contract with an individual, recording hours rather than results serves as a marker on which the relationship is reclassified as employment. Rebuilt the reporting around deliverables: blocks of work tied to items of the specification, a rate and a total stated in figures, and the hours column replaced by a basis of calculation. The transfer of rights clause was reworked against the default rules for commissioned software, with the consideration for the assignment stated separately.
OutcomeThe closing documents stopped working against the company. Rights in the development are evidenced by a document rather than inferred from a default rule.
