How to Set Up an Offshore Development Center (ODC) in Minsk: Legal, Tax, and Operational Roadmap

A pattern we’ve watched repeatedly over the past two years.

A foreign-owned ODC isn’t built the moment a company decides, “We should hire some engineers in Belarus.” It’s built much later — usually 18 to 36 months after the first Belarusian engineer signed on through an EOR, once the team has scaled past fifteen or twenty people, and once the operational control gap and the structural cost stack have begun to argue for a permanent presence on the ground.

The conversation usually starts with the COO or the head of finance, not with the head of engineering. The engineering side is typically happy with what they have. It’s the operational and financial side that begins to feel the friction — EOR margin compounding monthly, decisions that need a Belarus-based counterparty to sign things, IP chains that everyone hopes are clean but nobody has properly stress-tested. And the right answer, in our experience, isn’t always to convert.

This article walks through the framework. When an ODC is the right answer. When it isn’t, even when the team has reached the size where the conversation usually starts. And when the answer is yes, how the setup actually plays out in 2026 — including the parts that blow up timelines if you don’t see them coming.

ODC vs. EOR — the question before the question

Too many foreign clients ask “How do I set up an ODC in Belarus?” when the question they should be asking, honestly, is “Do I actually need one yet?” The setup work is structural. It costs time, attention, and political capital inside the foreign parent. If the team size and operational complexity don’t yet justify it, the right answer is to stay on the EOR model for another year and revisit. The question of when to convert deserves more space than it usually gets.

EOR remains the right answer when

• Team size is under 15–20 engineers and not trending sharply higher.
• The Belarus team is supporting a non-Belarus headquarters, and the engineers don’t need a direct contractual relationship with the foreign parent.
• Banking simplicity matters more than tax optimization at the current scale.
• The foreign parent doesn’t want the compliance, HR, and reporting overhead that a Belarusian entity carries — even an HTP-resident one.

ODC becomes the right answer when

• Team size has stabilised above 20 and is trending toward 40 or more.
• The Belarus operation needs commercial decision rights — signing local supplier contracts, leasing office space, building its own employer brand presence.
• EOR margin (typically 8–15% of total monthly payroll for an established relationship) starts to materially exceed the cost of running a local entity.
• Operational sovereignty — equipment ownership, office leases, local vendor relationships — becomes important to the business.
• The structural HTP advantages would be larger as a direct resident than as a client of an HTP-resident EOR.

This is the section the linear how-to articles tend to skip. We’re foregrounding it because the conversion decision is more consequential than the conversion mechanics. The mechanics are well-understood. The decision is what foreign founders sometimes get wrong, by deciding too early or by deciding too late.

The HTP framework — why almost every serious ODC ends up there

Most foreign-owned ODCs in Belarus are residents of the High-Tech Park. The alternative — a standard Belarusian limited liability company without HTP residency — is structurally uncompetitive for IT operations of any meaningful scale.

The High-Tech Park is the special legal and tax regime created for IT companies in Belarus. As of 2026 it hosts over a thousand resident companies, providing the operational framework that most foreign clients ultimately work through whether directly (as an ODC) or indirectly (as an EOR’s client).

The substantive HTP benefits, in summary:

• 9% personal income tax on engineer wages (versus the standard 13%).
• Social fund contributions calculated on the average national salary, not the engineer’s actual full salary — this is the structural saving that compounds fast at scale.
• 0% VAT on most IT services exports.
• 9% corporate profit tax (versus the standard 20%).
• Reduced rates on dividends and royalties for residents.
• English-language commercial contracts permitted.
• Elements of English commercial law accommodated in commercial agreements.
• Simplified residency procedures for foreign IT specialists.

Qualification turns on whether the company’s principal activity falls inside the HTP-permitted activity list (software development and a number of related categories all qualify). The Ministry of Economy HTP overview has the current details. In practice, foreign-owned IT companies that meet the activity criteria almost always qualify. The application process is procedural rather than discretionary, but it isn’t instant — typically 30 to 60 days from filing, sometimes longer if the business plan triggers additional review questions.

The legal entity setup, step by step

The actual mechanics walked through honestly. Not a checklist — a narrative of how the work sequences and where the time goes.

Entity type

Most foreign-owned ODCs in Belarus are limited liability companies. 100% foreign ownership is permitted. Minimum charter capital requirements are trivially low. Joint-stock company structures exist but are rarely used for ODC purposes; the LLC is the standard answer.

Registration

Through the territorial unified registration body for the district where the entity will sit. Core registration is typically 5 to 10 business days from filing — if the document set is complete. The document set includes founding documents, founder identification (apostilled and translated where the founder is foreign), proof of legal address, and the charter. Getting the document set complete is the part that takes time; the registration itself is fast once you’re ready to file.

HTP residency application

Separate process, usually run in parallel with entity registration or immediately afterward. Application includes the business plan (specific format), activity classification, founding documents, and supporting attachments. Approval typically 30 to 60 days. The administration occasionally comes back with clarification questions — building in a two-week contingency for this is wise.

Banking account opening

This is the step where timelines stretch most often. Foreign-owned entities face KYC processes that vary materially by bank. Some Belarusian banks have established workflows for foreign-owned IT entities and onboard them efficiently in four to six weeks. Others apply heightened compliance scrutiny that runs eight weeks or longer. The practical lesson: pick the bank early, start the conversation in week one, not week six, and treat the banking relationship as the gating dependency it usually is.

Tax registration and currency control

Tax registration is standard and runs in parallel with the entity setup. Currency control compliance deserves a specific mention. Belarus operates a currency control regime that affects how foreign-owned entities move money in and out. Manageable, but it needs to be set up correctly from the start — your first inbound payment from the foreign parent will be reviewed under currency control rules, and a smooth pass on that review is largely about having registered the relevant agreements correctly at the outset.

Personnel hire and onboarding

Either fresh hires into the new entity or — more commonly for clients with established EOR-based teams — conversion of existing engineers from the EOR into the new entity. The conversion path is the typical scenario for the audience this article is written for, and it is covered in its own section below.

Honest framing on overall timeline: a clean setup typically runs 3 to 4 months end-to-end. A rushed setup runs 2 months and accumulates problems that surface in year one. The right pace is the unrushed pace.

The EOR-to-ODC conversion — the path most readers are on

This is the specific scenario that applies to most foreign clients who ask the ODC question — they already have engineers in Belarus through an EOR and are converting to a directly-owned entity. The mechanics are well-trodden but easy to get wrong.

The sequence that works

Set up the ODC entity and obtain HTP residency before terminating EOR contracts. This sounds obvious; it isn’t always done. The window between the EOR contract ending and the new entity’s first payroll is the window where engineers feel uncertain about their employment status, where small problems become big ones, and where attrition risk is highest. Don’t open that window if you can avoid it. Run the new entity in parallel for a transition period.

Negotiate transition terms with the existing EOR early in the process. Most EORs cooperate with conversions — they understand that a client moving to ODC is a sign they did their job well. Some try to extract additional margin during the transition (longer notice periods, transition fees, charges for assistance with paperwork). Plan for both. Read the existing EOR contract specifically for the termination and transition clauses before you start, not after.

Re-hire each engineer into the new entity with continuity of service preserved where possible. Belarusian labour law has specific rules around continuity of service, vacation accrual, and severance — getting this right matters for engineer morale and for legal hygiene. Most local labour counsel will guide this in detail.

Transfer equipment ownership if the EOR was the legal owner. Negotiate this as part of the transition; some EORs sell at book value, others request a small premium.

Re-paper the IP assignment chain. This is the moment to fix anything that wasn’t clean originally. The new chain runs engineer → ODC entity → foreign parent (or, if the ODC is the foreign parent’s directly-owned subsidiary, engineer → ODC, with the parent owning the ODC and therefore indirectly the IP). Either way, get the assignment language fresh and clean. Don’t carry forward language from the previous EOR contracts without reviewing it.

Communicate the change to engineers carefully. The anxiety engineers feel during an employer change is real and well-founded — even when nothing actually changes for them in terms of compensation or working conditions. Clear, early communication and individual conversations prevent the avoidable attrition we’ve seen at clients who handled this less attentively.

Common conversion mistakes

• Setting up the new entity but starting payroll before HTP residency is granted — which forces the entity to operate under non-HTP cost structures for the first quarter and erodes the conversion economics.
• Terminating EOR contracts before the new entity’s banking account is operational.
• Forgetting to re-paper the IP assignment chain. The old chain (engineer → EOR → foreign parent) breaks when the EOR exits. A new chain has to be in place before the transition completes.
• Not communicating early to engineers. By the time HR explains the change, anxiety has spread informally and some engineers are already in recruiter conversations.

Operational setup — what the entity actually runs

Beyond the legal setup is the operational stack the entity needs to function. Quick walk-through of the components and how foreign clients typically resolve each.

Office or remote

Belarusian IT in 2026 is largely remote-first. The default for engineering work is hybrid or fully remote, and an entity can run that way without strict physical office requirements. That said, a small Minsk office signals seriousness, creates a center of gravity for the team, and provides a credible address for visiting clients and partners. Most ODCs settle into a small office (200 to 500 square meters) in central Minsk districts — Niamiha, Centralny, the area around Pobediteley Avenue — housing 30 to 50 hot-desks for a team of 60 to 80 engineers. Office lease costs are meaningful but not punishing — $15 to $30 per square meter monthly is typical.

HR and payroll

Either built in-house with a hired HR manager (and a chief accountant, which is required by law) or outsourced to a local payroll provider. The hybrid is most common — local payroll provider handles compliance and processing, in-house senior HR business partner handles people management. Pure outsourcing works at a smaller scale; once the team is past 40 engineers, an internal HR presence becomes valuable.

Compliance and accounting

Labor code compliance, tax filings, and HTP reporting. A chief accountant is mandatory for the entity by Belarusian law — the role can be filled in-house or, more commonly at a smaller scale, outsourced to a local accounting firm with the in-house team handling oversight.

Equipment procurement and lifecycle

Most ODCs handle this in-house once they hit 30+ engineers. Below that, working with a local IT supplier on a managed basis is simpler. Equipment ownership becomes part of the entity’s balance sheet, with tax and operational implications, but is generally cleaner than the EOR-owned equipment alternative.

Ongoing recruitment

Some ODCs build internal recruiting teams once they reach 50+ engineers. Most continue to retain a relationship with a local recruitment agency for ongoing search work, particularly for senior and specialised roles. Internal recruiters in Belarusian IT cost $2,500 to $4,500 monthly gross at the senior level — affordable, but the case for in-house recruitment is about ongoing volume rather than cost. External IT recruitment typically runs at the standard percentage of annual gross at hire, with terms that favour predictable volume.

Tax and financial mechanics — what the savings actually look like

The numbers behind the conversion decision. Comparing an HTP-resident ODC running the same team that previously ran through an EOR.

The headline tax differences for an HTP-resident entity versus a non-HTP entity (the EOR is HTP-resident for most foreign clients, so the relevant comparison is HTP-ODC versus HTP-EOR):

• Personal income tax: 9% (HTP resident) — same in both ODC and EOR cases when the EOR is HTP-resident.
• Social fund: calculated on the average national salary base — same in both cases.
• VAT on IT exports: 0% for both.
• Corporate profit tax: 9% — applies to both, calculated on the entity’s profits.
• EOR margin: 8–15% of total monthly payroll for an established relationship. This is the line that disappears when you move from EOR to ODC.

The structural saving in the ODC model is the EOR margin. Everything else is broadly comparable when both sides are HTP-resident.

Worked example

A 25-engineer team at $5,000 average gross monthly. Total gross payroll roughly $125,000 monthly.

EOR-routed total cost (gross payroll, employer-side contributions, benefits, EOR margin): approximately $175,000 to $190,000 monthly. The exact figure depends on the benefits richness and EOR margin tier.

HTP-resident ODC running the same team (same gross, same employer-side contributions, same benefits, no EOR margin, plus the entity’s own running costs — office, accounting, HR, equipment): approximately $145,000 to $160,000 monthly.

Monthly difference: roughly $20,000 to $30,000. Annually: $240,000 to $360,000.

Setup costs that offset this in year one: roughly $30,000 to $50,000 in entity setup, banking onboarding, HTP residency application, legal fees, office lease deposits, equipment purchases, and the time cost of the founder’s attention. Crossover from net cost to net saving typically occurs 12 to 18 months from setup, sometimes faster for larger teams.

Below 15 engineers, the math doesn’t work — EOR is cheaper end-to-end. Above 40 engineers, ODC is significantly cheaper. Between 20 and 40 engineers is the zone where the decision turns on factors beyond pure cost — operational control, employer brand, the strategic importance of the Belarus operation to the foreign parent.

Where the timeline blows up — the honest section

Where setup projects go wrong: observations across multiple conversions in 2024–2026.

Banking is the single biggest delay vector

Foreign-owned entities can face KYC processes that take four to eight weeks at the slow end. Some banks have efficient foreign-IT-client workflows; others do not. The practical lesson is to start the banking conversation in the first week of the setup, identify two or three candidate banks, and run the relationship-building in parallel with the entity registration. Treating banking as an afterthought is the single most reliable way to push the timeline from four months to seven.

Founder document apostille and legalization

Foreign founders consistently underestimate how long it takes to gather their home-jurisdiction documents. Notarised and apostilled copies of foundation documents, passport copies, proof of address, sometimes corporate good-standing certificates — all need to be obtained in the home jurisdiction, then apostilled, then translated into Russian (sworn translation by a recognized translator), and only then submitted in Belarus. Build in four weeks for this. It takes six.

HTP residency review questions

The HTP administration occasionally comes back with clarification questions on the business plan, particularly around activity classification or projected revenue. These questions aren’t a sign of trouble — they’re routine for non-standard cases. Build in two weeks of contingency for an exchange of clarifications.

Currency control on the first inbound payment

The entity’s first cross-border inbound payment from the foreign parent — typically the initial capitalisation or the first invoice — sometimes gets held by the bank for compliance review. Anticipated, not surprising, but it’s a process step that runs a few days to two weeks. Plan for it; don’t be caught with payroll due and incoming capital still under review.

Existing EOR cooperation

Some EORs cooperate fully and helpfully with conversions; others extract additional margin during the transition window. Read the existing EOR contract, specifically the termination, notice period, and transition cooperation clauses, before you start the conversion. Plan accordingly.

Engineer communication

The gap between “we’re moving you to a new entity” and “actually, nothing meaningful changes for you” is the gap where avoidable attrition happens. Brief engineers early, individually where possible. Pay particular attention to the senior contributors whose departures during a conversion would pose the greatest delivery risk. Some of them will be the most anxious about the change, precisely because they have the most to lose if things go wrong.

The bottom line

Setting up an ODC in Belarus is a project, not a decision made once and executed. Done well, it converts a 20-to-40-person Belarusian team from an EOR cost stack to a structurally cheaper, more controlled setup, with savings that compound year over year and a permanent base for future scaling. Done poorly, it produces a four-month project that becomes a seven-month project, an engineer cohort that loses confidence in the transition, and an IP chain that has to be cleaned up months after the fact.

The single most useful preparation is the question we opened with: Do you actually need an ODC right now, or are you 12 months early? If the answer is “early,” stay on the EOR model and revisit. If the answer is “now,” plan for the four-month case, build in contingency for six, and start the banking conversation before you start the entity registration.

At Recruitment.by we work with foreign clients on both sides of this decision — the EOR-based teams growing toward the conversion question, and the established ODCs running ongoing hiring. On the structural side of HTP residency, our HTP residency support and joining HTP services cover the application process and operational onboarding. For the broader organizational and compensation design that goes with scaling an ODC, our HR consulting handles the strategic side. Ongoing IT recruitment into the new entity, and supporting payroll and PEO services during transition, run alongside. For a conversation about your specific case — whether you’re at or beyond the threshold, or just wanting to model the trajectory — contact us.

NDA and IP Assignment Agreements in Belarus: Protecting Code When Hiring Remote Developers

Here’s a sentence that has cost companies their own product: “We paid for it, so we own it.” When the developers writing your code sit in Belarus, that assumption is wrong — or at least, it isn’t automatically right.

The US concept of “work made for hire,” where the employer owns the code the moment it’s written, is not how Belarusian law works. In Belarus, the exclusive rights to what your developer creates belong to your company only if you’ve explicitly said so — in the employment contract, or in a separate IP assignment agreement. Skip that step, or rely on a contractor arrangement with no assignment in it, and the rights can sit with the developer rather than with you. You can pay in full for code you don’t actually own.

Add the question of confidentiality on top — is your source code and roadmap genuinely protected if a developer walks out the door? — and you have two agreements that decide whether you control your most valuable asset or merely hope you do. This guide explains how NDAs and IP assignment actually work in Belarus, the work-for-hire mistake that catches foreign companies out, and what it takes to protect your code when the people writing it are remote. One note up front: this is general information from people who recruit in this market, not legal advice for your specific agreements — for those, use a qualified Belarusian IP lawyer.

The mistake that costs companies their code — you don’t automatically own it

Start with the assumption that does the damage, because almost everything else follows from clearing it up. Foreign companies — especially those used to US rules — tend to believe that paying a developer means owning what the developer produces. Money changes hands, code gets written, the code is yours. Under US “work made for hire,” that’s broadly true for employees. In Belarus, it isn’t the default at all.

Under Belarusian law, the exclusive rights to a work created by an employee belong to the employer only if that’s specified in the employment contract or a separate agreement. There’s no automatic transfer at the moment of creation. The Civil Code governs this — its intellectual-property section was reissued in a new edition that took effect in November 2024, which among other things enshrined a “presumption of creativity”: a work is presumed to be the product of the author’s creative effort unless shown otherwise, and the author holds the exclusive rights by default. The copyright term itself now runs for the author’s life plus seventy years. The thread through all of it: the rights start with the creator, and they only move to you if a document moves them.

The consequence is blunt. Without explicit assignment, you may be paying for code whose rights you don’t hold — effectively licensing your own product from the person you hired to build it, without either of you having meant that to happen. This isn’t a technicality to tidy up before an audit. It’s the difference between owning what you built and discovering, at the worst possible moment, that you don’t.

IP assignment — how to actually own what you pay for

The fix is straightforward in principle and worth getting exactly right in practice. IP assignment is the explicit transfer of the exclusive — that is, the economic — rights from the creator to your company. It can live inside the employment contract, or stand as a separate IP assignment agreement, but either way it has to be explicit, written, and signed. A vague gesture at ownership doesn’t do the job; the assignment has to actually say that the rights move.

A good assignment does a few specific things. It clearly transfers the exclusive rights to the work — the source code, the documentation, the related materials — to the company. It addresses the relationship between the background IP a developer brings with them (their pre-existing tools, libraries, prior work) and the foreground IP created for you, so the line between the two is clear. And it accounts for moral rights: in Belarus, as in much of the world, the author’s personal non-property rights, such as attribution, sit separately from the assignable economic rights and aren’t transferred the same way. A well-drafted assignment is written with that distinction in mind rather than pretending it away.

Two modern points are worth building in. First, AI-generated code: when developers use AI tools, who owns the output is a genuinely unsettled question in 2026, so the agreement should address AI-assisted work explicitly rather than leaving a gap. Second, timing. The assignment should be signed before work starts, not retrofitted once the code exists — a developer who has already written your core module and not yet assigned the rights is in a very different negotiating position from one signing an assignment on day one. Get the paperwork done at onboarding, alongside everything else.

Employee vs contractor — where the rights slip away

The ownership rule has two versions, and the difference between them is where most companies get hurt. It turns on whether your developer is an employee on an employment contract or a contractor on a civil one.

For an employee, the rights transfer to the employer only if the employment contract or a separate agreement says so. So the employment contract has to either contain the assignment or be paired with one — present it as a given, but make sure the document actually exists. For a contractor working under a civil or service contract, the position is sharper still: the rights remain with the creator unless they’re assigned. There’s no version of “the contractor obviously meant to hand over the code” in Belarusian law. If the service contract doesn’t assign the rights, the contractor keeps them, however much you paid.

Here’s why this matters so much for remote hiring specifically: a great many Belarusian developers are engaged as contractors, not employees. That’s precisely the arrangement where IP most easily stays with the developer, because the assumption that payment equals ownership is at its most wrong and the default most firmly favours the creator. Identify which relationship you actually have, and make the assignment explicit either way — but treat the contractor case as the one to be most careful about, because it’s the one that quietly costs companies their code.

NDAs and the trade-secret regime — confidentiality that actually holds

Owning the code is half the protection. The other half is keeping your confidential information — source code, architecture, roadmap, client data — from walking out with a departing developer. Here the news starts good: confidentiality clauses and NDAs are generally enforceable in Belarus. Then comes the catch that most employers miss.

Information is only protected as a trade secret if the company has actually taken steps to keep it secret — a complex of measures the law expects, often called the trade-secret regime. This isn’t a formality. The Supreme Court’s intellectual-property board has held that information which was freely accessible, or which the owner took no real measures to protect, simply doesn’t qualify as a protected trade secret, regardless of what a piece of paper says. An NDA sitting on top of nothing is an NDA resting on air. The signature doesn’t create the protection; the regime does, and the NDA enforces it.

So what does the regime look like in practice? You define what counts as confidential, document it (commonly in an internal regulation on trade secrets), limit access to the people who genuinely need it, and sign NDAs with everyone who sees the protected information — employees and contractors alike. The NDA itself should define what’s confidential, set the scope and how long the obligation lasts (during the engagement and after it ends), and spell out the remedies for breach. Built that way, the NDA does its job because there’s a real trade secret underneath it. Signed without the regime behind it, it’s a comfort blanket, not a defence.

Why you can’t lean on non-competes

One more expectation worth correcting, because companies often reach for it. A non-compete clause — the kind that tries to stop a departing developer from joining a competitor or starting a rival — is subject to strict limitations under Belarusian law. You cannot rely on it the way some US companies do, and treating it as your main line of defence is a mistake.

The protection has to come from the two tools that do work: a strong IP assignment, so the departing developer takes no ownership of your code with them, and a strong confidentiality regime, so they can’t lawfully use or disclose your secrets. Don’t build your strategy on a non-compete that may not hold. Build it on the assignment and the trade-secret regime, which do.

The practical checklist — protecting code when hiring remote in Belarus

None of this is exotic. It’s standard practice, and the companies that come unstuck are almost always the ones who assumed US rules applied. The short version:

• Identify the relationship first. Employee or contractor — the IP rules differ, and the contractor case is the higher-risk one.
• Assign IP explicitly, in writing, before work starts. In the employment contract or a separate agreement; cover source code, documentation, and the line between background and foreground IP.
• Address AI-assisted code in the assignment, since ownership of AI output is still unsettled.
• Build a trade-secret regime, not just an NDA. Define and document what’s confidential, limit access, and take the measures the law actually expects.
• Sign NDAs with everyone who sees confidential information — employees and contractors — with clear scope, duration, and remedies.
• Don’t rely on non-competes. They’re strictly limited; lean on assignment and confidentiality instead.
• Keep the paperwork trail. Who signed what, and when. Clean chain-of-title is exactly what an investor or acquirer will ask to see.

Two scenarios from practice

Scenario A. The contractor who owned the code

A foreign startup engaged a Belarusian developer as a contractor to build a core module, paid in full, and shipped the product. The service contract said nothing about IP assignment — the founders assumed, as founders often do, that paying for the work meant owning it. The product worked, the company grew, and nobody thought about it again.

Then an investor’s due diligence asked for clean chain-of-title to the code, and the gap opened up. Under the civil contract, with no assignment, the exclusive rights to that core module had stayed with the developer the whole time. What should have been a single signature at the start became a renegotiation under pressure, mid-financing, with the developer now holding leverage nobody had intended to give them. The deal survived, but it was a bad few weeks and a worse precedent. The lesson is plain: with a contractor in Belarus, paying for the work is not the same as owning the rights. The assignment has to be explicit — and it costs a signature at the start or a great deal more later.

Scenario B. The NDA that held because the regime was real

A company hiring Belarusian developers did the unglamorous groundwork before it needed to. It defined its confidential information, wrote it into an internal trade-secret regime, limited access to the codebase and the product roadmap to the people who actually needed it, and had every developer sign an NDA tied to that regime. It felt like over-preparation at the time.

It wasn’t. When a developer left for a role at a competitor, the confidentiality obligations were enforceable — not because of the signature alone, but because the company had taken the real measures the law requires, so the protected information genuinely qualified as a trade secret. The NDA wasn’t a standalone scrap of paper; it sat on a foundation that made it mean something. The lesson pairs with the first: an NDA is only as strong as the trade-secret regime beneath it. Build the regime, and the NDA does its job when it matters.

Own it on purpose, protect it for real

When you hire remote developers in Belarus, owning your code and protecting your secrets aren’t automatic — they’re the result of two agreements done properly. IP assignment, because Belarusian law doesn’t hand you ownership the way US work-for-hire does; you have to take it explicitly, and most of all with contractors. And an NDA built on a real trade-secret regime, because confidentiality is only enforceable when you’ve taken the measures the law actually requires. Non-competes won’t save you. The assignment and the regime will.

The companies that keep control of their code are the ones that signed the right paperwork before the first line was written — not the ones who discovered the gap during due diligence or after a developer left. It’s a signature at onboarding versus a crisis later, and the difference between the two is entirely a matter of doing it on purpose, up front. Own it deliberately. Protect it for real. Everything else is hoping.If you’re hiring developers in Belarus and want to do it so your code and your secrets are actually protected — the right agreements, signed at the right time, for the relationship you actually have — get in touch with us. We place IT professionals across the Belarusian market and help employers structure hiring that holds up — including the onboarding paperwork that keeps your IP yours. One more time, because it matters: this article is general information, not legal advice. For your specific NDA and IP assignment agreements, work with a qualified Belarusian IP lawyer who can draft for your situation.

Stock Options and Employee Equity for Belarusian IT Employees: What’s Legally Possible

Equity is a standard part of the package in tech now. Stock options at a startup, RSUs at a scale-up, a slice of ownership meant to tie talented people to the company’s success. For Belarusian IT engineers — among the most sought-after in the region — equity offers are increasingly common, and almost always from a foreign employer or parent company.

That last detail is where the questions begin. Can a Belarusian employee legally receive and benefit from foreign equity? What happens at tax time? Does currency control complicate it? Most equity guidance online is written for someone sitting in San Francisco or Berlin, and it quietly assumes a tax and legal context that simply doesn’t hold when the employee is in Minsk.

This article looks at what’s actually possible — and what’s actually required — for a Belarusian IT employee with equity. The mechanics of options and RSUs, the Belarusian tax reality of foreign-source income, the currency and documentation side, and an honest bottom line: it’s possible and increasingly normal, but it rewards understanding the rules before you sign, not discovering them at tax-return time. One caveat up front, and we’ll repeat it, because it matters: equity taxation is genuinely complex and turns on the specifics of each grant. This is general information from people who recruit in this market — not tax or legal advice for your particular situation.

The mechanics — options vs RSUs, and how equity actually works

Before the Belarus layer, the universal part: what you’re actually being offered. Two instruments dominate, and they behave differently.

Stock options give you the right to buy shares at a fixed price — the strike price — once they vest. If the company’s value climbs above that strike, the options are worth something; if it doesn’t, they aren’t. RSUs, restricted stock units, work the other way around: they’re a promise of actual shares delivered to you on vesting, with nothing to buy. An RSU keeps some value unless the share price falls to zero, which makes it the lower-risk of the two from the employee’s side. Options carry more upside and more risk; RSUs carry steadier, smaller value.

Both come with vesting — the schedule that earns you the equity over time, typically three to five years, often with a one-year cliff. The cliff means nothing vests in the first year; stay past it and the equity starts accruing, usually monthly or quarterly, until it’s fully vested. So the lifecycle runs grant, then vesting, then — for options — exercise, then eventually sale. Each of those points can carry tax consequences, and understanding which instrument you hold and where you are in its lifecycle is the foundation everything else sits on. Get that clear first; the Belarusian layer attaches to specific points along it.

The foreign-company reality — why this is almost always cross-border

Here’s the fact that shapes everything else for a Belarusian employee, and the one the Western guides skip entirely. Your equity almost always comes from a foreign company — a foreign startup, the foreign parent of a local entity, a foreign client that became an employer. That single fact is what pulls Belarusian rules into the picture.

Foreign-issued equity is foreign-source income and foreign property. Which means the rules that apply to it aren’t only the issuing company’s home-country rules — they’re also Belarus’s rules on how its tax residents are treated on income and assets from abroad. And tax residency is a low bar to clear: spend more than 183 days in Belarus in a calendar year and you’re a Belarusian tax resident, taxed on your worldwide income. For most Belarusian IT employees, that includes the equity. So the mental model isn’t “I have shares in a US company, so US rules apply.” It’s “I’m a Belarusian tax resident receiving foreign-source income, so Belarusian rules apply too” — on top of whatever the issuing country does.

The tax reality — foreign-source income, self-declared

This is the central section, and the one to read most carefully. Income that a Belarusian tax resident receives from a foreign source — including income in kind, such as shares or securities — is foreign-source income subject to Belarusian personal income tax, at the standard rate of 13%. (The High-Tech Park rate has historically been lower and has shifted in recent years, so the exact rate for HTP-linked employees is worth confirming for the current year; the IT-sector tax picture is covered in our overview of taxes in IT companies in Belarus.)

The part that surprises people most is who handles it. Foreign-source income is self-declared. The foreign employer doesn’t withhold Belarusian tax — it can’t — so the obligation sits with the employee. In practice that means filing a personal income tax return by 31 March of the year after the income arose, and paying the tax by 1 June. Miss those and the problem is yours, not the company’s. Equity income doesn’t arrive with Belarusian tax already handled the way a salary does; it arrives as something you have to declare yourself.

Then there’s the currency question, which has a precise answer. Foreign-currency amounts are converted into Belarusian rubles at the official National Bank exchange rate on the date the income is actually received — and for income in kind, such as shares, that date is when the shares are transferred to you. So the value you declare isn’t a round number you choose; it’s the market value on a specific date, converted at a specific rate. Belarus also has a wide network of double-taxation treaties — around seventy — which matter where you’ve also paid tax abroad, because they bear on whether and how you can credit that foreign tax. That, too, is grant-specific.

Here’s where the honesty has to be loudest. Exactly when the taxable moment falls — at vesting, at exercise, at sale, or some combination — and exactly how the value is measured at that moment is genuinely intricate, and it varies by instrument and by the structure of the plan. This is not a place for a rule of thumb. The principle is clear and worth internalising: foreign equity income is taxable in Belarus and you declare it yourself. The application to your specific options or RSUs needs individual professional advice. Anyone who tells you otherwise about a complex cross-border equity grant is overselling their certainty.

The currency and documentation side

Beyond the tax itself, there’s the practical machinery of holding foreign shares from Belarus — and it rewards being organised from the start rather than scrambling later.

Receiving, holding, and eventually selling foreign shares — usually through a foreign broker — sits within Belarus’s currency-regulation framework, the same framework that governs other cross-border financial flows. It doesn’t make equity impossible; it makes it something to handle deliberately. And the documentation burden is real. To declare correctly you’ll want the grant notice, the vesting reports, the broker statements, and proof of any foreign tax you’ve paid — kept from the moment of grant, not assembled in a panic the following March. Reconstructing a multi-year vesting history from memory at tax time is exactly the kind of avoidable pain that turns a good opportunity into a stressful one.

One more practical thread: because tax residency turns on days of presence, anyone whose work involves real mobility — time abroad, relocations, remote stints in other countries — should keep records of it. Border crossings, travel documents, the basic trail. Residency can be the difference between owing Belarusian tax on the whole grant and owing it on part, and the records are far easier to keep as you go than to reconstruct after.

What’s possible — and what to be realistic about

So, the honest payoff to “what’s legally possible.” It is possible, and increasingly normal, for a Belarusian IT employee to receive and genuinely benefit from foreign equity. This isn’t a grey area to be nervous about; it’s an established part of how international tech compensates talent, and Belarusian engineers are well inside that world.

What makes it work smoothly is unglamorous: a clearly documented grant from a reputable foreign employer, understood up front, with the tax and currency steps planned rather than discovered. What to stay realistic about is equally plain. The tax is self-declared, and that obligation is yours. The value is often illiquid — shares in a private company can’t be turned into cash until a liquidity event like an IPO or acquisition, which may be years away or may never come. The FX and documentation steps are real work. And the rules can change, as rules do. None of that makes equity a bad deal. It makes it a real one — an opportunity that rewards going in informed rather than dazzled by the headline number.

For employers and recruiters — offering equity to Belarusian talent

The other side of the table matters too. Foreign companies recruiting Belarusian IT talent can offer equity, and increasingly need to in order to compete with the firms that already do. But there’s a right way to do it, and it isn’t just attaching a big notional number to the offer.

The companies that get value from equity offers to Belarusian hires are the ones that present them clearly — with documentation the employee can actually use for their Belarusian obligations, and with honest framing about tax, vesting, and liquidity. The recruiter’s role in that is real: explaining the equity component credibly, setting realistic expectations, and not overselling. A candidate who understands their offer — including the Belarusian tax and currency reality — values it correctly and doesn’t feel misled a year later when the tax return lands. That’s the same standard of clarity we bring to placing IT professionals generally; our IT recruitment services are built around matching strong candidates with roles where the whole package, equity included, is understood on both sides. And because the legal frame around hiring matters as much as the offer, our guides to the probationary period in Belarus and to background checks and candidate verification cover the adjacent ground every employer hiring here should know.

Possible, increasingly normal, and worth understanding first

Equity for Belarusian IT employees is legally possible and increasingly part of the landscape — almost always foreign-sourced, which is exactly what brings Belarusian tax and currency rules into play. The income is taxable and self-declared, the value converts to rubles at the National Bank rate on the date of receipt, and the documentation matters from the very first grant notice. The taxable-event mechanics are genuinely complex, so individual professional advice on a specific grant isn’t a nicety — it’s the sensible default.

For employers, offering equity to Belarusian talent is a competitive advantage when it’s done clearly and documented honestly. For candidates, it’s a real opportunity — best understood before signing rather than puzzled over a year later. The headline number on an equity offer is where the conversation starts. What it means for someone sitting in Belarus is where the real understanding begins.

If you’re a company recruiting Belarusian IT talent and want to build offers — equity included — that candidates understand and value correctly, or you’re navigating the hiring landscape here and want a partner who knows it, get in touch with us. We place IT professionals across the Belarusian market and help employers structure offers that hold up on both sides. A quick, important note: this article is general information, not tax or legal advice — for your specific equity grant, speak to a qualified tax professional who can see the plan documents.