什么是往账和来账（Nostro 与 Vostro）？面向开发者的代理银行指南

如果你曾开发过支付功能，并好奇资金究竟是如何跨境流动的，答案几乎总是离不开两个有着奇怪拉丁名字的账户：往账（nostro）和来账（vostro）。它们是每一笔国际电汇、汇款和多币种付款背后的管道。大多数关于往账与来账的讲解只停留在词典式的定义。本指南更进一步：用通俗的语言解释这个概念，带你走一遍完整的复式记账示例，然后展示如何使用汇率 API 在代码中对这些余额进行建模、估值和对账。如果你开发金融科技、资金管理或会计软件，这正是你需要的思维模型。

什么是往账和来账？

Nostro 和 vostro 源自意大利语（经由拉丁语）：nostro 意为“我们的”，vostro 意为“你们的”。它们是同一个账户的两个标签，只是从银行关系的相对两侧来看。

• 往账（nostro）是“我们的钱存放在你们那里”。它是一家银行在境外银行开立、以外币计价的账户。在本国银行的账簿上，它是一项资产。
• 来账（vostro）是“你们的钱存放在我们这里”。它就是同一个账户，只是从保管资金的银行角度来看。在其账簿上，它是一项负债。

对开发者而言的关键洞见：往账和来账不是两个不同的账户，而是从两个视角描述的同一个账户。 A 银行称其在 B 银行的美元往账，B 银行则称其为对 A 银行的来账。相同余额、相同交易、两套账簿、相反符号。

这是经典示例。一家德国银行需要为其客户办理美元付款，但它在美国没有分支机构，也没有直接的美元清算渠道。于是它在一家美国代理银行开立美元账户，并把美元存放在那里。

• 对德国银行来说，那个美元账户是一个往账（“我们的美元，放在那边”）。
• 对美国银行来说，同一个账户是一个来账（“德国人的美元，放在我们这里”）。

往账与来账：关键区别

区别完全在于视角。下表加以概括：

转账账户（loro）在何处

偶尔你会看到第三个术语 loro（“他们的”）。loro 账户并不是一种新账户，而是一家银行在谈及属于另外两家银行的账户时使用的指代。如果 A 银行谈论 B 银行为 C 银行保管的账户，A 银行就称之为 loro 账户。它主要在多银行支付链条的 SWIFT 报文表述中起到清晰化的作用；你很少需要直接对它建模。

这些账户为何存在：代理银行业务

没有哪家银行在每个国家都设有分行，也没有哪家银行直接接入每个国家的本地清算系统。代理银行业务解决了这个问题。规模较小的“委托行（respondent）”与规模较大、确实拥有本地渠道的“代理行（correspondent）”合作，并在其处预先注资一个往账。这样，委托行无需搭建任何本地基础设施，就能提供该币种的付款。

一家大型银行可能在全球维护数十个往账——每个需要结算的币种一个——每个都是预先注资的流动性资金池。另一侧，一家大型代理行为全球数百家委托行运行数百个来账。在这些账户之间移动余额的指令，以标准化报文的形式通过 SWIFT 网络传输（越来越多采用 ISO 20022 格式）。

这就是为什么一笔“简单”的跨境付款可能会经过三四家银行，耗时一到三天，并在途中被手续费和汇差吃掉一部分。每一跳都是对某处某个往账或来账余额的一借一贷。

完整示例：往账/来账对之间的复式记账

跟着资金走，概念很快就会变得具体。假设 FNBA（澳大利亚的一家银行）在 CMB（美国的一家银行）持有一个美元往账。FNBA 以约定汇率向客户 C 出售 100 万澳元，换取 200 万美元。

在 FNBA 的账簿上（其往账是一项美元资产）：

Dr  USD Nostro @ CMB          2,000,000 USD
    Cr  FX Trading (USD)          2,000,000 USD

Dr  FX Trading (AUD)          1,000,000 AUD
    Cr  Customer C (AUD)          1,000,000 AUD

在 CMB 的账簿上，同一个美元账户是一个来账（它欠 FNBA 的一项负债）：

Dr  Customer C (USD)          2,000,000 USD
    Cr  FNBA Vostro (USD)         2,000,000 USD

注意这种镜像：FNBA 借记其往账，以记录它拥有的更多美元；CMB 贷记同一个来账，以记录它欠下的更多美元。把两家银行对该账户的看法相加，按设计它们会对账为零。这种镜像正是关键所在——也正是你的对账代码将要利用的特性。

作为开发者对往账/来账余额进行建模

如果你开发资金管理、账务或支付软件，无需成为一家银行也能使用这个模型。任何代表他人持有多币种余额的系统——多币种钱包、市场平台的付款引擎、新型银行的总账——都面临同一个问题：你以多种币种持有真实余额，且必须以单一本位币报告其合计价值。

从一个最小的表结构开始。每个往账式余额只不过是一个币种、一个金额，以及保管它的对手方：

CREATE TABLE nostro_balances (
    id            BIGSERIAL PRIMARY KEY,
    correspondent TEXT NOT NULL,        -- who holds the funds
    currency      CHAR(3) NOT NULL,     -- ISO 4217 code, e.g. 'USD'
    balance       NUMERIC(20,4) NOT NULL DEFAULT 0,
    updated_at    TIMESTAMPTZ NOT NULL DEFAULT now()
);

一旦你持有超过一种币种，就会出现一个报告问题：此刻以我们的本位币计，合计价值是多少？ 你不能直接把美元、欧元和日元相加——必须先按当前汇率给每个余额估值。这正是汇率 API 发挥作用的地方。下面是一个 Python 函数，用于以选定的本位币给一组往账余额估值：

import requests

FINEXLY_KEY = "YOUR_API_KEY"

def value_nostros(balances, home="EUR"):
    """balances: dict of {currency: amount}. Returns total in `home`."""
    symbols = ",".join(c for c in balances if c != home)
    resp = requests.get(
        "https://api.finexly.com/v1/latest",
        params={"base": home, "symbols": symbols},
        headers={"Authorization": f"Bearer {FINEXLY_KEY}"},
        timeout=5,
    )
    resp.raise_for_status()
    rates = resp.json()["rates"]   # e.g. {"USD": 1.0842, "JPY": 161.4}

    total = 0.0
    for currency, amount in balances.items():
        if currency == home:
            total += amount
        else:
            # rates[X] = units of X per 1 home unit, so divide to convert back
            total += amount / rates[currency]
    return round(total, 2)

nostros = {"USD": 2_000_000, "JPY": 500_000_000, "GBP": 750_000}
print(value_nostros(nostros, home="EUR"))

该 API 调用返回一个干净的汇率对象——{"base": "EUR", "date": "2026-08-08", "rates": {"USD": 1.0842, ...}}——因此把每个外币余额换算回本位币只需一次除法。关于该端点及其参数的完整说明，请参阅汇率 API 文档；如果你是新手，免费货币 API 套餐足以把整套原型搭起来。

往账对账与汇兑损益

真实的往账运营中有两个问题最为突出，而且都明确属于开发者的工作。

1. 对账。 由于往账与其镜像来账必须一致，对账就意味着把你对该账户的内部记录与代理行发来的对账单（如今通常是 SWIFT MT940/camt.053 报文）进行匹配。你账簿上的每一笔分录都应在对方账簿上有对应分录。差异——一侧有而另一侧没有的分录——意味着一笔缺失、重复或延迟的交易，需要在其演变成流动性或合规问题之前予以调查。上面示例中的镜像特性，正是自动匹配得以实现的原因。

2. 汇兑重估。 往账余额以外币持有，但你以本位币报告。由于汇率会波动，一笔静止的外币余额换算成本位币的价值每天都在变化。这个差异就是未实现汇兑损益，会计准则要求予以确认。做法是：在余额建立时记下当时的汇率，与今天的汇率对比，并把差额入账。

const FINEXLY_KEY = "YOUR_API_KEY";

async function fxGainLoss(currency, amount, rateAtBooking, home = "EUR") {
  const url = `https://api.finexly.com/v1/latest?base=${home}&symbols=${currency}`;
  const res = await fetch(url, {
    headers: { Authorization: `Bearer ${FINEXLY_KEY}` },
  });
  const { rates } = await res.json();
  const currentRate = rates[currency];        // currency units per 1 home unit

  const valueAtBooking = amount / rateAtBooking;
  const valueNow = amount / currentRate;
  return {
    home,
    valueAtBooking: +valueAtBooking.toFixed(2),
    valueNow: +valueNow.toFixed(2),
    unrealizedPnl: +(valueNow - valueAtBooking).toFixed(2),
  };
}

// 2,000,000 USD booked at 1.0800, revalued at today's rate
fxGainLoss("USD", 2_000_000, 1.08).then(console.log);

对于期末报告和审计留痕，你还会需要历史汇率，而不只是实时汇率——获取某个过去日期的准确收盘汇率。这正是历史汇率端点的用途，它对于数月后重现某个月末的重估至关重要。随着你的余额数量和对账频率增长，请查看价格方案以匹配你的请求量；一个每隔几分钟就刷新数十种币种的资金管理面板，累计起来会很快。

如果你想在这些余额之上向终端用户提供实时换算——比如让客户看到以其本币计价的付款——托管的货币换算器或同一个 latest 端点即可直接驱动。

现代替代方案：往账/来账走向何方

往账/来账模型已有数百年历史，至今仍承载着大部分跨境价值，但其摩擦——被困在数十个账户中的预注资流动性、多日结算、不透明的费用——已促使行业转向替代方案：

1. SWIFT gpi 在既有代理银行轨道之上增加了端到端追踪和当日结算，而无需替换这些账户。
2. 稳定币和代币化存款 让机构无需在每种币种上预先注资往账，即可在数分钟内完成结算，尽管监管明确性仍在追赶之中。
3. 央行数字货币（CBDC）和批发结算试点（多家央行正在测试跨境走廊）旨在彻底缩短中介链条。

不过，对于你未来几年将开发的大多数软件而言，这些账户——以及上面的对账和重估逻辑——不会消失。理解它们是一项持久的技能。

常见问题

往账和来账有什么区别？ 它们是同一个账户的两侧视角。从拥有资金的银行看，往账是“我们的钱在你们那里”（一项以外币计的资产）；从保管资金的银行看，来账是“你们的钱在我们这里”（一项以本币计的负债）。

往账是资产还是负债？ 往账在拥有它的银行的资产负债表上是一项资产——它代表该行存放在代理行的自有资金。镜像的来账对保管这些资金的银行则是一项负债。

银行为什么需要往账和来账？ 因为没有哪家银行在每个国家都有分行或直接的清算渠道。由往账/来账余额支撑的代理关系，让一家银行能够在自己没有本地存在的币种上收付款项。

如何对往账进行对账？ 把你对该账户的内部总账与代理行的对账单（例如 SWIFT camt.053）进行匹配。每一笔分录都应在两侧出现；无法匹配的分录（“差异”）需要调查。由于往账与来账互为镜像，两套记录应当净额为零。

汇率 API 如何帮助往账/来账核算？ 余额分布在多种外币中，但你以单一本位币报告。汇率 API 提供了给每个余额估值、计算未实现汇兑损益并生成一致的多币种报告所需的实时和历史汇率。

亲自试试

准备好用真实汇率给多币种余额估值和对账了吗？获取你的免费 Finexly API 密钥——无需信用卡。从每月 1,000 次免费请求开始，获取 170 多种货币的实时和历史汇率，并随着你的资金管理逻辑增长而升级。