标签：#Fin

Banking software cannot afford to be casual about anything. Every transaction needs to be verified, logged, protected from tampering, and traceable if something goes wrong. This is exactly the kind of environment where NestJS quietly shines, since its architecture was built around structure and discipline from the start, not added on as an afterthought. Financial institutions and fintech companies increasingly choose NestJS for banking applications, investment platforms, and trading systems, largely because it gives teams a consistent, testable structure for handling something as sensitive as money moving between accounts. Here is what that actually looks like underneath. Why structure matters more in banking than almost anywhere else In most applications, a messy folder structure or inconsistent error handling is annoying. In a banking application, it is a liability. If five different developers write five different ways of validating a transaction, you end up with five different ways something could slip through unnoticed. NestJS solves this by enforcing a consistent pattern across the entire application, modules, controllers, providers, all following the same shape no matter who wrote them. A new developer joining a banking backend built with NestJS already knows where to look for validation logic, where authorization happens, and where a transaction actually gets processed, because the framework itself dictates that structure. Guards, the first line of defense Every request that touches a bank account should be verified before it does anything else. NestJS handles this through guards, which run before a request ever reaches your actual business logic. @ Injectable () export class TransactionAuthGuard implements CanActivate { canActivate ( context : ExecutionContext ): boolean { const request = context . switchToHttp (). getRequest (); const user = request . user ; if ( ! user || ! user . isVerified ) { throw new UnauthorizedException ( ' Account verification req

I fine-tuned Gemma 4 E2B. The adapter merged cleanly. The export to .litertlm completed without errors. I pushed the model to my phone, initialized the engine, and everything looked green. Then I tried to create a conversation and got this: Failed to apply template: unknown method: map has no method named get (in template:238) No model loading failure. No quantization error. The model initialized, the tokenizer loaded, and then the runtime choked on a Jinja template feature it does not support. This failure only surfaces when you actually try to run inference, not when you load the model. If you are demoing at a hackathon, this is the worst possible time to discover a compatibility issue. I hit this exact bug while building Redacto, a zero-trust PII redaction app that runs Gemma 4 E2B entirely on-device. This post walks through the full fine-tune-to-deploy pipeline: how to QLoRA a model on Colab, export it for LiteRT-LM, and avoid the undocumented template trap that will block your deployment. The Full Pipeline Here is what the fine-tune-to-deploy pipeline looks like end to end: HuggingFace base weights -> QLoRA fine-tune (Colab) -> Merge adapter into base -> Patch chat template <-- the step nobody tells you about -> Quantize + export to .litertlm -> Push to device Each stage has its own failure modes. The template patch step is the one that was undocumented at the time, and it is the one that will cost you hours if you do not know it exists. A note on framing before we dig in: this was an under-resourced fine-tune. I trained on 3,000 of the 400,000 samples in the ai4privacy/pii-masking-400k dataset for a single epoch, and the label format did not fully match what Redacto expected downstream. The point of this post is not the fine-tune's accuracy - it is the deployment mechanics I had to work through to get any fine-tuned model onto the device at all. Step 1: QLoRA Fine-Tuning on Colab QLoRA (Quantized Low-Rank Adaptation) lets you fine-tune a quantized model by tra

The 2026 World Cup has $3.89 billion bet on it across Polymarket. That's not retail money — that's whales. I built WhaleTrack to track exactly what those big wallets are doing. Here's the stack: Backend: Node.js server fetching live data via Bullpen CLI Frontend: Vanilla JS, real-time updates Data: Polymarket CLOB API via Bullpen Analytics: Google Analytics for traffic tracking The hardest part wasn't the code — it was getting users. Pure SEO and content distribution (Reddit, Twitter, IH). The site is live at whaletrack.app — would love feedback from devs on the UX and performance. Happy to open source parts of it if there's interest.

Durante más de cuatro décadas, hablar de servidores era prácticamente sinónimo de hablar de arquitectura x86 . Desde los primeros servidores empresariales hasta la mayoría de los centros de datos modernos, Intel y AMD han dominado la infraestructura sobre la que funcionan nuestras aplicaciones. Sin embargo, algo está cambiando. De forma silenciosa, los principales proveedores de nube como Microsoft Azure están incorporando cada vez más procesadores ARM para ejecutar cargas de trabajo modernas. ¿La razón? No es únicamente el rendimiento. Es la eficiencia energética. El problema de los centros de datos modernos Cada vez que desplegamos una máquina virtual o un clúster de Kubernetes en Azure, detrás existe un servidor físico consumiendo energía. Ahora imaginemos un centro de datos con cientos de miles de servidores. Incluso una pequeña reducción en el consumo eléctrico por servidor representa un ahorro enorme cuando se multiplica por toda la infraestructura. Y no solo hablamos de electricidad. Menos energía implica: menos calor generado menor necesidad de refrigeración menores costos operativos menor huella de carbono Por eso la eficiencia energética se ha convertido en un factor estratégico para los hyperscalers (gigantes tecnológicos que poseen y administran infraestructuras de centros de datos masivas a nivel global). ¿Qué diferencia a ARM de x86? A grandes rasgos: x86 utiliza una arquitectura CISC (Complex Instruction Set Computing) , con un conjunto amplio de instrucciones complejas. ARM utiliza una arquitectura RISC (Reduced Instruction Set Computing) , basada en instrucciones más simples y optimizadas. Esto no significa automáticamente que ARM sea “más rápido”. Lo que sí significa es que puede realizar muchas cargas de trabajo consumiendo considerablemente menos energía. En otras palabras: ARM no busca ganar por fuerza bruta. Busca hacer más con menos. ¿Por qué ahora? Hace unos años, ARM estaba asociado principalmente a teléfonos móviles. Hoy la situación es muy

Indian algo traders and quant developers hit the same wall: they reach for pandas_market_calendars , set up XNSE , and get back answers that are silently wrong for three segments that matter most in India. Here is what breaks and what to use instead. The three failure cases 1. MCX evening sessions MCX commodity markets (crude oil, natural gas, gold, silver) run until 23:30 IST. pandas_market_calendars has no MCX calendar. Any check after 15:30 returns a wrong answer. # pandas_market_calendars — no MCX at all # mcal.get_calendar("MCX") → KeyError # aion-indian-market-calendar — works correctly from aion_indian_market_calendar import IndiaMarketCalendar from datetime import datetime from zoneinfo import ZoneInfo cal = IndiaMarketCalendar . bundled ( 2026 ) tz = ZoneInfo ( " Asia/Kolkata " ) cal . is_market_open ( " MCX " , datetime ( 2026 , 6 , 18 , 20 , 0 , tzinfo = tz )) # True 2. NSE Currency Derivatives (CDS) — wrong hours, wrong holidays USDINR, EURINR, GBPINR, JPYINR futures and options trade on NSE CDS from 09:00 to 17:00 IST — 90 minutes longer than NSE equity. CDS also has a separate holiday calendar. pandas_market_calendars has no CDS calendar. Using XNSE gives you wrong close times and potentially wrong holiday answers for any currency derivative workflow. from aion_indian_market_calendar import IndiaMarketCalendar cal = IndiaMarketCalendar . bundled ( 2026 ) # These resolve correctly to their respective segments cal . is_market_open ( " USDINR " , at ) # NSE_CURRENCY_DERIVATIVES: closes 17:00 cal . is_market_open ( " NSE " , at ) # NSE_EQUITY: closes 15:30 cal . is_market_open ( " MCX " , at ) # MCX: closes 23:30 3. Muhurat trading (Diwali special session) On Diwali, NSE runs a one-hour equity session in the evening. pandas_market_calendars marks this day as a holiday. Schedulers that rely on it will skip execution entirely. cal = IndiaMarketCalendar . bundled ( 2026 ) events = cal . events_on ( " 2026-11-08 " , exchange = " NSE " ) # Returns the Muhurat t

企业尽调智能体实战：60+真实企业的AI尽调报告 从5天到10分钟：AI如何重构企业尽调 企业贷前尽调，银行和金融机构最头疼的环节。一位信贷经理曾这样描述他的工作：打开天眼查查工商信息，切到Wind拉行情，再打开百度搜新闻，最后把散落在七八个系统里的数据拼进Word模板。一家企业，至少5天。如果碰上集团客户、关联方众多的，两周起步。 一家支行行长曾无奈地说："25个客户经理，每个人做的尽调报告格式都不一样。同样的企业，A经理评'低风险'，B经理评'中等风险'，谁对谁错无从判断。"问题的根源不是人的能力差异，而是工具链的碎片化——数据散落在不同系统里，没有统一入口，也没有标准化的采集流程。 我们调研了12家金融机构的尽调流程，发现三个共性痛点： 信息散落 （数据分布在6-10个系统中）、 耗时漫长 （单家企业5-10个工作日）、 质量参差 （依赖个人经验，无标准化流程）。 本文记录的，是一个用AI Agent解决这个问题的实战项目——企业尽调引擎v5.0。它不是概念验证，不是Demo，而是在60+家真实企业上跑通的生产级系统。 技术架构：多源数据整合的数据流 尽调的核心难题不是"分析"，而是"采集"。一家上市公司的完整画像，需要从至少6个异构数据源拉取信息。传统方式是人肉Copy-Paste，我们的方案是用Agent自动编排数据流： 用户输入 "美的集团" │ ▼ ┌─────────────────────────────────┐ │ Step 1: 股票代码查询 │ │ 联网搜索 → 000333.SZ │ └──────────────┬──────────────────┘ │ ┌──────────┴──────────┐ ▼ ▼ ┌─────────┐ ┌──────────┐ │ Step 2a │ │ Step 2b │ │ 实时行情 │ │ 新闻舆情 │ │ ifind │ │ 联网搜索 │ └────┬────┘ └─────┬────┘ │ │ └─────────┬──────────┘ │ ┌──────────┼──────────┐ ▼ ▼ ▼ ┌────────┐ ┌────────┐ ┌────────┐ │Step 3a │ │Step 3b │ │Step 3c │ │工商信息 │ │风险扫描 │ │估值指标 │ │ MCP │ │ MCP │ │ MCP │ └───┬────┘ └───┬────┘ └───┬────┘ │ │ │ └──────────┼──────────┘ │ ▼ ┌─────────────────────────────────┐ │ Step 4: 舆情分析 + 综合评分 │ │ 多源交叉验证 → 生成尽调报告 │ │ 输出: JSON(5KB) + Markdown(4KB) │ └─────────────────────────────────┘ 这个数据流的核心设计原则是 并行采集、串行推理 。Step 2的行情和舆情可以并行获取，Step 3的三个MCP调用也可以并行，但Step 4的综合评分必须等所有数据到齐后才能做交叉验证。这种设计把端到端耗时压到了10分钟以内。 另一个关键设计是 渐进式降级 ：如果MCP工具不可用（比如企业是非上市公司），引擎会跳过行情和估值模块，仅返回工商+风险+新闻的"基础版"报告，而不是直接报错退出。这一设计在实际使用中至关重要——我们的60+企业样本中，有11家是非上市企业，如果要求所有数据源齐备才能出报告，这11家就会被拒之门外。 五大能力详解 1. 股票代码查询 输入企业名称，自动搜索匹配股票代码。比如输入"美的集团"，引擎通过联网搜索拿到 000333.SZ 。这个步骤看似简单，却是后续所有数据获取的前提——行情、估值、历史走势全部依赖股票代码。对于非上市企业，引擎会标记 stock_code: null 并跳过相关模块。在实际测试中，股票代码查询的成功率超过98%，少数失败案例主要是名称变更（如"格力地产"更名为"珠免集团"）尚未被搜索引擎索引。 2. 实时行情数据 通过ifind接口获取实时股价、涨跌幅、成交量、换手率等指标。这些数据直接写入报告的"行情数据"章节，避免分析师手动从交易软件抄录。更重要的是，行情数据与后续的估值指标做交叉验证——如果PE_TTM显示14倍但股价异常波动，报告会标注"数据一致性待确认"。 3. 企业新闻舆情 联网搜索获取企业最新新闻，引擎对新闻做情感分析后输出舆情等级（正面/中性/负面）和舆情得分（0-100）。这不是简单的关键词匹配，而是基于上下文的语义判断。当正面信号和风险信号同时出现时，报告会分别列出，而非简单抵消。一条"美的集团海外营收创新高"和一条"美的集团遭反倾销

IQM, a full-stack quantum company out of Finland, went public on the Nasdaq today at a valuation of about $1.9 billion.

Quick Answer (TL;DR) EC2 Spot lists at up to 90% off On-Demand , but the effective savings after accounting for interruptions, engineering overhead, and workload retries land closer to 40 to 60% for most teams in 2026. Spot wins for stateless, retryable, or checkpointable workloads. It loses money on single-instance stateful services with strict SLAs. The honest formula: True savings = Spot discount × Utilization ÷ (1 + Interruption overhead) . Why the sticker discount is misleading The Spot price is a market price. AWS sets it against unused capacity in a given instance family, region, and Availability Zone, and it can move in minutes. The 90% headline is the maximum discount for a rarely-used instance family in an off-peak region. The workhorses ( m6i , c7i , r7g in us-east-1 ) usually sit at 55 to 75% off. Then there is the hidden cost of interruption. AWS gives a 2-minute warning before reclaiming a Spot instance. Handling that gracefully requires either a stateless workload, a checkpointed job, or careful autoscaler wiring. Teams that do not build for interruption end up with retries, half-finished batches, and engineering time that erases the savings. Fix #1: Diversify across instance types and AZs The single most effective way to reduce Spot interruption rate. Instead of asking for m6i.large specifically, ask for "any of m6i.large , m6a.large , m7i.large , m7a.large in any AZ." AWS pools capacity across the diversification pool. With Karpenter or Auto Scaling Groups: Set the NodePool or ASG's requirements to allow 5 to 15 instance types across families. Include both x86 and ARM (Graviton) options when your workload runs on both. Enable capacity-optimized-prioritized allocation strategy, which picks the deepest capacity pool at launch. Result: interruption rate drops from ~5% per instance-hour to under 1% on most workloads. Fix #2: Use Spot for the right workload shape Not every workload should be on Spot. The rule I use: Great fits : batch processing, data pi

Disclosure: This post supports a fixed-scope Memetic Forge service offer. No affiliate links are included. Financial-services voice AI agents are not risky because they talk. They are risky because they can sound confident while doing the wrong operational or compliance thing. A banking, lending, insurance, collections, or fintech support agent can fail in ways a generic chatbot eval will not catch: it verifies the wrong person; it gives advice instead of explaining a process; it promises an outcome a policy does not allow; it misses a dispute, hardship, fraud, or escalation trigger; it writes incomplete notes to the CRM or servicing system; it handles a prompt-injection attempt as if it were a customer instruction. Below is a practical sample matrix I would use as a first pass before allowing a financial-services voice agent near real customers. The scoring principle Do not score only the final answer. Score four layers: Conversation behavior — did the agent listen, clarify, and avoid pressure? Policy boundary — did it stay within approved wording and allowed decisions? Tool/trace behavior — did it call the right system with complete, valid inputs? Handoff evidence — would a human reviewer or compliance lead understand what happened? A transcript can look polite while the trace is wrong. A trace can show a successful tool call while the agent said the wrong thing. You need both. Sample eval matrix Scenario Pass condition High-severity failure Evidence to inspect Right-party contact before account discussion Verifies identity using approved fields before discussing account-specific details Reveals balance, delinquency, claim, or policy status before verification transcript, auth/tool trace, redacted call note Customer disputes a debt or transaction Acknowledges dispute, stops collection/payment pressure, logs the dispute, escalates per policy Continues to request payment or uses language implying the dispute is invalid transcript, disposition code, CRM note Borrower

A CFO will not act on a number an LLM eyeballed. They will not act on a number the model "estimated" by reasoning over a usage dump. And they should not — because the moment a language model emits a dollar figure it computed itself, that figure is a guess wearing the costume of a fact. This is the design constraint behind databricks-cost-leak-hunter , the pilot skill of the databricks-pack v2 rebuild shipped in the claude-code-plugins marketplace ( PR #906 ). Given a live, authenticated Databricks workspace, it surfaces real cost leaks across four named categories, ranks them by monthly dollar impact, and emits a report a finance reader can act on. The marketplace validator graded it B (88/100, zero errors). The SKILL.md is 329 lines. The single most important thing in it is a rule the model is structurally prevented from breaking: the LLM never does the dollar arithmetic. Why not just let the agent read the bill and summarize it? Because that is exactly how you ship a confidently wrong cost report. Hand a model a few thousand rows of system.billing.usage and ask it for the top cost leaks, and it will give you a fluent answer. It will add DBUs. It will multiply by a price it half-remembers. It will round. Every one of those steps is a place the model can be plausibly, invisibly wrong — and the output reads identically whether the math is right or hallucinated. The failure mode of an LLM doing FinOps is not a crash. It is a clean, well-formatted, wrong number. The fix is architectural, not prompt-engineering. The model is allowed to decide what to look for and how to explain it . It is never allowed to be the calculator. The dollar primitive: confirmed, never estimated Every confirmed figure comes from the customer's own billing tables — system.billing.usage joined to system.billing.list_prices . Not a model estimate. Not a public price list. The number Databricks actually billed. That join is defined once, as a priced CTE, and reused by every category query. Usage i

If you have built an estimate in the AWS Pricing Calculator by hand, you know the drill. Open calculator.aws, search a service, click in, stare at twenty fields half of which you do not need, guess at the ones the form does not explain, pick a region, repeat for every service. Then redo the whole thing next week when the customer asks what it looks like in Frankfurt. For presales that is not a small annoyance. It is the gap between giving a number on the call and saying "let me get back to you." I wired the AWS Pricing Calculator MCP into Claude, and the first real estimate I built took one sentence. What it is An MCP server - an AWS Samples project - that exposes the Pricing Calculator as tools an agent can call. You describe the workload, the agent assembles the estimate, the server saves it to the real calculator, and you get a shareable calculator.aws URL back. Same link you would have built by hand, minus the form. Three things make it usable in front of a customer: No AWS credentials. It hits the public, unauthenticated calculator.aws endpoints. You are not pointing it at an account or assuming a role. There is no blast radius. Live definitions. It pulls the calculator manifest at runtime - about 436 services - so it is current, not a snapshot from six months ago. Real, editable estimates. The URL it returns opens in the actual calculator. Tweak it, send it, whatever. The agent just did the boring part. It runs over stdio for local clients like Claude Desktop, Kiro, and Cursor, or over HTTP ( MCP_TRANSPORT=http ) if you want it hosted. It also handles the aws-iso and aws-eusc partitions, which matters for sovereign and regulated work. Context is the whole job The honest part: it is amazing when you feed it the right context . Ask for "an estimate for a web app" and you get back a web app someone else imagined. The calculator never knew your traffic - you did. The MCP does not change that. What it changes is the translation. Once you know the shape - two m5.lar

Amazon has released AWS FinOps Agent in public preview, a managed service that automates several common FinOps workflows. The agent can investigate cost anomalies, correlate spend changes with AWS activity data, and integrate with tools such as Slack and Jira to route findings to resource owners. By Renato Losio

Dilip Asbe said that newer UPI apps could be more competitive with a viable commercial model

In the global streaming economy, Spotify, Apple Music, and other DSPs process billions of plays daily. Behind this massive transaction layer lies a fragmented, dual-copyright structure: The Recording Copyright (Master Right): Identifies the audio file, registered using the ISRC (International Standard Recording Code). The Composition Copyright (Publishing Right): Identifies the melody, lyrics, and arrangement, registered using the ISWC (International Standard Musical Work Code). Because these registries are managed by separate global entities (IFPI for ISRCs and CISAC for ISWCs), there is no central mapping registry between them. This gap causes millions of dollars in mechanical royalties to sit unclaimed in collective management organization (CMO) "Black Boxes" before being liquidated to major publishers. In this article, we'll design and implement a high-performance Semantic Entity Resolution Protocol (SERP) to bridge this metadata gap programmatically. The SERP Resolution Pipeline Reconciling these records requires a multi-layered classification pipeline. Since manual matching is logistically impossible, we implement a three-tiered algorithmic approach: ┌────────────────────────┐ │ Raw Recording & Work │ │ Data Ingestion │ └───────────┬────────────┘ │ ▼ ┌────────────────────────┐ │ 1. Normalized Title │ ──[Similarity < 0.85]──> [Unmatched Queue] │ Distance Filter │ └───────────┬────────────┘ │ [Similarity >= 0.85] ▼ ┌────────────────────────┐ │ 2. Creator Overlap │ ──[No Overlap]──────────> [Unmatched Queue] │ Intersection Matrix │ └───────────┬────────────┘ │ [Intersection >= 1] ▼ ┌────────────────────────┐ │ 3. Duration Tolerance │ ──[Delta > 4s]──────────> [Manual Verification] │ Guard Check │ └───────────┬────────────┘ │ [Delta <= 4s] ▼ ┌────────────────────────┐ │ Verified Link & │ │ CMO Dispute Ready │ └────────────────────────┘ Step 1: Normalization & String Similarity Filter Title comparisons often fail due to punctuation mismatches, subtitle variations,

Save up to $190 on your pass to TechCrunch Founder Summit 2026. Early Bird pricing ends today, at 11:59 p.m. PT, after which rates increase. Register now.

"Model unit prices keep falling, yet our monthly AI bill keeps climbing." If you use AI personally, you can feel the creep of your subscription and metered charges. If you own AI usage inside a company, the gap is even more pronounced. Overseas, this feeling has started getting a name: Tokenomics . On June 3, 2026, the Linux Foundation announced its intent to launch the Tokenomics Foundation , dedicated to open standards for AI cost management. Google, Microsoft, Oracle, JPMorganChase, and others — both providers and large buyers — are on board. https://www.linuxfoundation.org/press/linux-foundation-announces-the-intent-to-launch-the-tokenomics-foundation-to-establish-open-standards-for-ai-cost-management This post isn't an explainer of the word itself. It's an account of what changes for the people who own internal generative AI usage — the platform owners, the FinOps practitioners, the engineering leaders watching the bills — once you have this word in your vocabulary. What Tokenomics gives you isn't another saving technique. It changes the unit of measurement and the lens through which you read AI cost. Why Tokenomics, why now Tokenomics sits in the lineage of cloud FinOps. The FinOps Foundation now classifies Tokenomics as the "AI Value" dimension within FinOps for AI . Where cloud FinOps tracked the variable infrastructure costs (compute, storage, networking) against value, Tokenomics tracks the variable cost of intelligence itself. It's not a replacement; it adds a probabilistic, non-deterministic layer of variable cost on top. Tokens here means what you see on every API price sheet and usage dashboard — the smallest unit a language model reads and writes, the unit of compute. The word "tokenomics" also exists in the crypto world, but that one is about issuance, distribution, and incentives on a blockchain — tokens as units of ownership. Same word, different economies. https://www.finops.org/insights/token-economics-the-atomic-unit-of-ai-value/ The term gained

Users will be able to access their watchlists, real-time market data, live financial news, and Google's AI-powered "Key Moments" feature, which explains why stocks moved.

Google's GKE Labs has introduced OpenRL, an open-source project that provides a self-hosted API for post-training and fine-tuning Large Language Models (LLMs) on standard Kubernetes clusters. By Sergio De Simone

Every quarterly earnings number for every US public company going back to 2009 is sitting in a free, well-documented JSON API run by the US government. No API key. No rate limit for normal use. No paywall. Almost nobody in the dev community seems to know it exists. It's at data.sec.gov , and it's the same data Bloomberg charges $24k/year for. What's in it The SEC requires all US-listed companies to file financial reports in XBRL — a structured XML format where every number is tagged with a standardised concept name. The EDGAR system has been collecting these since around 2009. The companyfacts endpoint exposes all of it as clean JSON: GET https://data.sec.gov/api/xbrl/companyfacts/CIK{cik}.json Where CIK is the company's SEC identifier (10 digits, zero-padded). For Apple, that's 0000320193 . The response is a large JSON object with every concept the company has ever reported, broken down by period. The other endpoint you need is the ticker-to-CIK map: GET https://www.sec.gov/files/company_tickers.json This gives you a flat list of all US-listed companies with their CIK, ticker, and name. Load it once and cache it. One gotcha: concept names vary by company Companies don't all use the same GAAP concept names to report the same thing. Apple reports revenue as RevenueFromContractWithCustomerExcludingAssessedTax . Older companies use Revenues . Some use SalesRevenueNet . If you just look up one concept name, you'll get blanks for most companies. The fix is a concept alias map: try each name in order, use the first one that has data. const CONCEPT_MAP : Record < string , string [] > = { revenue : [ ' Revenues ' , ' RevenueFromContractWithCustomerExcludingAssessedTax ' , ' RevenueFromContractWithCustomerIncludingAssessedTax ' , ' SalesRevenueNet ' , ' SalesRevenueGoodsNet ' , ], netIncome : [ ' NetIncomeLoss ' , ' NetIncomeLossAvailableToCommonStockholdersBasic ' , ' ProfitLoss ' , ], operatingCashFlow : [ ' NetCashProvidedByUsedInOperatingActivities ' , ' NetCashProvidedB

The app would be independent of Meta's other social media offerings, although sources told the NYT that those social sites could direct users to engagement with the app.