我目前正在评估使用 Plaid 或 Yodlee 进行事务聚合（我现在都在使用 Dev 环境）。我真的更喜欢 Plaid 的几乎所有内容，但我在交易名称/描述方面遇到了麻烦。 Yodlee 有一个名为“简单描述”的数据字段：
从他们的文档中：“出现在 FI 网站上的交易描述可能不是不言自明的，即交易的来源、目的可能并不明显。Yodlee 试图简化交易并使交易对消费者有意义，并且在简单描述字段中提供了这种简化的交易描述。”
我正在向最终用户显示交易名称，并且我正在寻找比交易名称字段更用户友好的内容，该字段通常返回诸如“取款支票卡 MOE'S BROADWAY BAGE BOULDER CO 日期 01/06/19 0 9006020339 0 5812 卡 [XXXX]”。
我敢肯定，我不是第一个有这种需求的格子花呢顾客。 Plaid 依赖应用如何解决这个问题？
【问题讨论】：
据我所知，Plaid 没有提供简单的描述字段，但它们确实会清理交易名称。
我发现当有新的待处理交易进入时，名称就像您提到的那样混乱（例如UBER *TRIP 5VVB2）。但是一旦交易被确认，Plaid 就会针对普通商家（例如Uber）对其进行规范化。我不知道为什么 Plaid 不为待处理的交易提供这种规范化，但我之前已经向他们提出过。也许这在未来可能会改变？
一个解决方案，尽管很复杂，是构建一个标准化交易名称的自定义模型。这就是我们在 Pluto Money 为补充 Plaid 的交易数据所做的工作。
【讨论】：
我收到了来自 Plaid Support 的电子邮件的直接回复：
感谢您在 Plaid Support 上与我们联系，我很抱歉 我们的延迟。
我们每笔交易的姓名字段代表我们尽最大努力 平衡详细的交易信息，同时提供一个干净和 一致的 API 响应。这种行为确实因银行而异，两者 由于银行行为和我们自身的整合质量。一般在 大型银行 我们的整合在恢复清洁方面做得更好 带有适当交易细节的交易名称，但对于某些 我们较小的银行交易名称可能更“原始”。
如果您从不想要商家/交易之外的其他详细信息 在您的应用程序中的名称我会鼓励您实施一些过滤 格子名称字段以确保没有日期或帐号之类的 字符串传递到面向用户的流中。
【讨论】：